In case you're wondering what is happening in my life, please see the title. No new events, no crazy nights, no fun vacations. Until December. When hopefully things will pick up.
I should get a hobby. That involves people. Hmmmmm.
2010-11-19
2010-09-30
LISP at work!?!?!
I get to use LISP at work! A standard CAD program, Cadence's icfb, uses a SKILL-based API. SKILL has a LISP-like syntax. I need to automate creation of a large number of cells, and the SKILL API is the easiest way to do that. This is going to be awesome!
2010-09-21
2010-09-16
Science disappoints
Nothing makes me distrust a journal as much as ignorance of the state-of-art.
From a 2008 article in Nature Photonics!:
From a 2008 article in Nature Photonics!:
To date it has been thought that APDs are unable to measure the number of photons in a pulse of radiation or a short time interval.And yet, from an article published four years earlier about APDs, we see:
A technique has been developed and tested that permits estimation of the photon number involved in a detection process.Wow. Just wow. I would have thought the reviewing process for Nature Photonics would be rigorous. I guess you can't believe everything you read.
Open source!
I'm going to be creating an open source library with all of my models - woohoo! Now if only I could decide on which license to use - current contenders are BSD, MIT, GPL and apache. Hmmmm.
2010-07-07
Makefile for \LaTeX
Due to some recent discussion on my previous LaTeX post, I thought I'd share the biggest advantage I think LaTeX has over WYSIWYG editors like MSWord: interaction with text tools.
First, let me paint you a few scenarios. You have images that you want to use in multiple places, like presentations, papers, and maybe even that PhD thesis you are planning on writing in a few years. However, the image format is going to vary from document to document; some documents, like presentations, call for much larger fonts, whereas your PhD thesis is going to have a clipped image size compared to any papers you'll publish. You want to be able to quickly reconfigure a set of images to have the same look and feel. You also want to view, easily, what processing you used on the image several years from now after you've forgotten everything you did.
Another scenario: a person is writing a book chapter and comes to you about using a variation of one of your images that she has seen in a paper of yours. She asks you to produce a variation of it.
Third scenario: one of your colleagues discovers a bug in an analysis script. You need to quickly track down all data that uses this script, and see if it affects any of your published data.
Fourth scenario: you're trying to remember exactly how you analyzed a set of data, but you performed the experiment several months back and can't remember the exact method you used to produce a figure in one of your presentations.
Fifth scenario: you're modifying a script that creates a figure, and you're concerned about comparing the different possibilities and still getting the final version correct. How do you track all the changes?
These scenarios illustrate three important ideas when publishing data: reproducibility, traceability, and configurability. I am going to share my method of (mostly) solving these problems using LaTeX and the make utility.
Make is a text-based utility that is normally used for dependency tracking in large programs. Back in the day, when compiling took a lot more time than it does now, it was important that code was only compiled when it was necessary. When a program called a library, it wasn't necessary to re-compile the library every time the program was changed. The make program is used to track these dependencies, but it is actually general enough to track a lot of dependencies, such as images in a LaTeX file.
Let me give you an example. Say you have a LaTeX file that includes two images: A.jpeg and B.jpeg. Both are created by eponymous scripts A.exe and B.exe. A.exe, though, relies on a lot of really complicated processing performing by complexProcess.exe. You also want to have the same look and feel for both images.
This is quite simple to accomplish if you are familiar with the make utility. You can create a Makefile that looks like the following, which tracks the dependencies of your data and processing:
To create makeItem, make checks that the dependencies are met. If makeItem and the dependencies are files, then make checks if the dependency files were last modified after the makeItem file, and will only run the commands if this is the case. In the Makefile example, A.jpeg depends on A.exe and tempFileFromProcessing. If either A.exe or tempFileFromProcessing has been modified after A.jpeg, then make will run ./A.exe (which should create A.jpeg). Similarly, tempFileFromProcessing depends on the processing script, complexProcess.exe, and experimentalData. If either complexProcess.exe or experimentalData has changed after the temp file, the processing will be re-run. This allows you to cache or save complicated processing, but still gives traceability into what processing occurs.
Making the file B.jpeg is simpler to understand, as it just depends on B.exe. If B.exe has changed after B.jpeg, make will run ./B.exe, which should create B.jpeg.
The same thing can be done with tables or experimentally derived values by having LaTeX include another .tex file that is generated by a script.
Getting LaTeX and BibTeX to generate a file can be a bit complicated. Using make erases this problem, as it does the same thing every time. To make the pdf, you'd type "make pdf" which would cause make to run latex, then bibtex, then latex, then latex again. You could type "make viewPdf" which would also tell adobe acrobat to show you the PDF file.
If you need to see which images depend on a specific script, you can have the script print out caller information (or use a logging utility) to check what data is passing through any buggy scripts. Just change the script and re-make the pdf, and you'll have all the contaminated data calls.
Okay, so this fixes two problems, namely reproducibility and traceability. It also makes it easy to change the file and see the results. You can change which experimental run you use for experimentalData, for example, to see how your A.jpeg varies based on which run you're presenting. But what about configurability? How do you make the plots look the same for each document, but use the same plotting scripts across documents?
You can accomplish that by using a convention for look-and-feel in the figure generation files. For example, you can pass a file to all of your scripts that contains information like the font, font size, and figure size to create. This allows easy configurability.
So there you have it - the biggest strengths of LaTeX compared to programs like MSWord. You can create documents that use the same plotting scripts, but with different look-and-feels, for publications, presentations, posters and theses. It is easy to trace the source of plots when you need to come back to that publication in four years but you forgot the exact processing. You get caching of complex processing. Finally, it is easy to track down what published data has images run through contaminated scripts. The fact that LaTeX is compiled gives you superior traceability, configurability, and reproducibility of your data compared to WYSIWYG editors like MSWord.
First, let me paint you a few scenarios. You have images that you want to use in multiple places, like presentations, papers, and maybe even that PhD thesis you are planning on writing in a few years. However, the image format is going to vary from document to document; some documents, like presentations, call for much larger fonts, whereas your PhD thesis is going to have a clipped image size compared to any papers you'll publish. You want to be able to quickly reconfigure a set of images to have the same look and feel. You also want to view, easily, what processing you used on the image several years from now after you've forgotten everything you did.
Another scenario: a person is writing a book chapter and comes to you about using a variation of one of your images that she has seen in a paper of yours. She asks you to produce a variation of it.
Third scenario: one of your colleagues discovers a bug in an analysis script. You need to quickly track down all data that uses this script, and see if it affects any of your published data.
Fourth scenario: you're trying to remember exactly how you analyzed a set of data, but you performed the experiment several months back and can't remember the exact method you used to produce a figure in one of your presentations.
Fifth scenario: you're modifying a script that creates a figure, and you're concerned about comparing the different possibilities and still getting the final version correct. How do you track all the changes?
These scenarios illustrate three important ideas when publishing data: reproducibility, traceability, and configurability. I am going to share my method of (mostly) solving these problems using LaTeX and the make utility.
Make is a text-based utility that is normally used for dependency tracking in large programs. Back in the day, when compiling took a lot more time than it does now, it was important that code was only compiled when it was necessary. When a program called a library, it wasn't necessary to re-compile the library every time the program was changed. The make program is used to track these dependencies, but it is actually general enough to track a lot of dependencies, such as images in a LaTeX file.
Let me give you an example. Say you have a LaTeX file that includes two images: A.jpeg and B.jpeg. Both are created by eponymous scripts A.exe and B.exe. A.exe, though, relies on a lot of really complicated processing performing by complexProcess.exe. You also want to have the same look and feel for both images.
This is quite simple to accomplish if you are familiar with the make utility. You can create a Makefile that looks like the following, which tracks the dependencies of your data and processing:
A.jpeg: A.exe tempFileFromProcessingThis looks complicated, but it is quite simple. The Makefile has the structure
./A.exe
tempFileFromProcessing: complexProcess.exe experimentalData
./complexProcess.exe
B.jpeg: B.exe
./B.exe
viewPdf: pdf
acrobat paper.pdf
pdf: paper.tex paper.bib
latex paper
bibtex paper.bib
latex paper
latex paper
dvipdf paper.dvi
makeItem: dependencyOne dependencyTwo
commandOne
commandTwo
To create makeItem, make checks that the dependencies are met. If makeItem and the dependencies are files, then make checks if the dependency files were last modified after the makeItem file, and will only run the commands if this is the case. In the Makefile example, A.jpeg depends on A.exe and tempFileFromProcessing. If either A.exe or tempFileFromProcessing has been modified after A.jpeg, then make will run ./A.exe (which should create A.jpeg). Similarly, tempFileFromProcessing depends on the processing script, complexProcess.exe, and experimentalData. If either complexProcess.exe or experimentalData has changed after the temp file, the processing will be re-run. This allows you to cache or save complicated processing, but still gives traceability into what processing occurs.
Making the file B.jpeg is simpler to understand, as it just depends on B.exe. If B.exe has changed after B.jpeg, make will run ./B.exe, which should create B.jpeg.
The same thing can be done with tables or experimentally derived values by having LaTeX include another .tex file that is generated by a script.
Getting LaTeX and BibTeX to generate a file can be a bit complicated. Using make erases this problem, as it does the same thing every time. To make the pdf, you'd type "make pdf" which would cause make to run latex, then bibtex, then latex, then latex again. You could type "make viewPdf" which would also tell adobe acrobat to show you the PDF file.
If you need to see which images depend on a specific script, you can have the script print out caller information (or use a logging utility) to check what data is passing through any buggy scripts. Just change the script and re-make the pdf, and you'll have all the contaminated data calls.
Okay, so this fixes two problems, namely reproducibility and traceability. It also makes it easy to change the file and see the results. You can change which experimental run you use for experimentalData, for example, to see how your A.jpeg varies based on which run you're presenting. But what about configurability? How do you make the plots look the same for each document, but use the same plotting scripts across documents?
You can accomplish that by using a convention for look-and-feel in the figure generation files. For example, you can pass a file to all of your scripts that contains information like the font, font size, and figure size to create. This allows easy configurability.
So there you have it - the biggest strengths of LaTeX compared to programs like MSWord. You can create documents that use the same plotting scripts, but with different look-and-feels, for publications, presentations, posters and theses. It is easy to trace the source of plots when you need to come back to that publication in four years but you forgot the exact processing. You get caching of complex processing. Finally, it is easy to track down what published data has images run through contaminated scripts. The fact that LaTeX is compiled gives you superior traceability, configurability, and reproducibility of your data compared to WYSIWYG editors like MSWord.
2010-06-17
Compacting Conference Papers in LaTeX
I have a conference submission due next week with one page of text and two pages of figures. I had to compact this submission like crazy, so I thought I'd post my notes in case anyone else finds them helpful. "Anyone else" includes a future me.
Achieving no line breaks requires two things. First, you have to find the *.bst file that LaTeX uses and copy it to your local directory under a different name. For example, I was using the "ieeetr" style file, so I copied ieeetr.bst from the location LaTeX uses to my local directory as myieeetr.bst. You then must modify this file, and comment out the "newline$" strings in the output item. So in my case, the item
Next, you have to add the following to the top of your .tex file before \begin{document} but after the usepackageslazypragmatic user. If you modify the ieeetr bst file to do this please send it to me!
Margins
I used the geometry package to get my margins correct.\usepackage[left=0.5in,right=0.5in,vmargin=0.8in,nohead,nofoot]{geometry}Title
Unfortunately LaTeX doesn't seem to handle compacting titles, authors and affiliations very well. My start looks like this:\centerline{\Large \bf Title Goes Here}
\medskip
\centerline{Author~Name~One, Author~Two$^{\rm \dagger}$, and
Author~Three$^{\rm \dagger*}$}
\centerline{Primary Author Institution, Address, Country}
\centerline{ phone: +1-123-456-7890, fax: +1-234-567-8901, email:
user.name@institution.edu }
\centerline{$\dagger$Affiliation $*$Affiliation}
\bigskip
%% Text starts hereFigures
I used the vspace command quite liberally to shrink the space between the pictures and the captions. An example follows. The "[h!]" command after the "\begin{figure}" tells LaTeX to try really hard to keep the same ordering as in the .tex file.\begin{figure}[h!]
\vspace{-25pt} %% moves figure closer to previous caption
\centering
\includegraphics[width=3.5in]{figure_file.pdf}
\vspace{-5pt} %% moves the caption closer to the figure
\caption{\textbf{Figure title} - a detailed description of the figure.}
\label{fig:block}
\end{figure}Equations
I embedded my equations in a figure to save space. I also used the vspace command to help with space between equations.\begin{figure}[h!]
\centering
\vspace{-20pt}
\begin{equation}
\label{eq:one}
\frac{\partial c}{\partial t} = D\frac{\partial^2 c}{\partial x^2}
\end{equation}
\begin{equation}
\label{eq:two}
{\rm SNR} = 20\log_{10}\left(\mu\right)
\end{equation}
\begin{equation}
\label{eq:three}
\Delta{\rm SNR} = 10\log_{10}\left( f )
\end{equation}
\includegraphics[width=0.01in]{blank}
\vspace{-10pt}
\caption{\textbf{Equations}. Eq.~\ref{eq:one}
is foo, while Eqs.~\ref{eq:two}
and \ref{eq:three} are bar.}
\label{fig:eq}
\end{figure}Bibliography
I spent the most time messing around with my bibliography. I wanted no line breaks between the items, the bibliography in a smaller font, only the first author listed and no titles in the items.Achieving no line breaks requires two things. First, you have to find the *.bst file that LaTeX uses and copy it to your local directory under a different name. For example, I was using the "ieeetr" style file, so I copied ieeetr.bst from the location LaTeX uses to my local directory as myieeetr.bst. You then must modify this file, and comment out the "newline$" strings in the output item. So in my case, the item
FUNCTION {output.bibitem}
{ newline$
"\bibitem{" write$
cite$ write$
"}" write$
newline$
""
before.all 'output.state :=
}became (notice the %'s before the two newline$'s)FUNCTION {output.bibitem}
{ %newline$
"\bibitem{" write$
cite$ write$
"}" write$
%newline$
""
before.all 'output.state :=
}Next, you have to add the following to the top of your .tex file before \begin{document} but after the usepackages
\usepackage{paralist}
\renewenvironment{thebibliography}[1]{\begin{inparaenum}[[1{]}]}{\end
{inparaenum}}I have no idea what that command does, but my bibliography didn't have any line breaks. The bibliography stanza that comes after my main text ends is (and you should use whatever you named the local file in place of "myieeetr")\medskipTo shorten the bibliography even further, I removed all "TITLE={...}," lines from my bibtex file, and replaced the non-first authors with the "others" string. This causes a bibliography item to look like
\bibliographystyle{myieeetr}
\footnotesize{
\bibliography{myBibtexFileName}
}
[1] M. Smith, et al., Journal Name, vol. 99, pp. 123–123, Jan. 2000.which is exactly what I wanted. If I was a manly user I'd modify the bst file to do this, but I'm only a
Columns
I used one column for the text and "\twocolumn" before the figures to help with reducing dead-space.Page Numbers
I used a "\pagestyle{empty}" at the start to remove page numbers.Fonts
Adding a "\usepackage{times}" will help with using slighter smaller fonts.Conclusions
I hope some of these notes will be helpful if you want to use LaTeX for conference papers. It was a bit challenging at first, but I'm very happy with the final results. Please let me know if you have any trouble getting things to work above; I'd be more than happy to send you my .tex files so you can see how things worked for me.2010-05-31
Superb Supercomputer Treemap
The BBC has a spectacular Supercomputer Treemap. It is definitely the classiest visualization I've seen all day. I suggest checking it out, along with the historical article on treemaps.
2010-05-19
ACM Survery of Graphs
ACM has an interesting survey of graph types. I don't like most of them, *especially* graph types like the stacked graphs in 1B that introduce correlations into the visual representation of the data that aren't in the data. The splom in Figure 2C, however, is a very nice representation that I'd never seen before.
2010-05-18
Greater than One?
Nothing increases my faith in science like seeing a highly cited article that experimentally measures a probability larger than one. Hmmmmmmmmm.
2010-05-14
Game Review: Dwarf Fortress
I've been pretty hosed at work lately, so I apologize for the lack of recent posts. It is hard to write a blog when you've spent the past few weeks writing a paper (or three) at work. However, I just wanted to practice my non-technical writing and talk a bit about a Dwarf Fortress, a game that I thought I'd review.
The game has three modes: fortress, adventure and legend. All three modes center on different aspects of a single world - for the sake of brevity I'll be focusing solely on fortress mode, which is a mode similar to Sim City but with a fortress instead of a city. Adventure is a hack-and-slash mode similar to NetHack, and legend is an encyclopedic mode that is still in the works.
The basic premise behind the game is all there in the title. You have dwarves, and you want to build a fortress in the side of a mountain (mountain optional). If you enjoyed playing Sim City, you'll probably enjoy Dwarf Fortress, though it has a *much* steeper learning curve. There isn't an end goal to the game, though as your fortress gains wealth and population your fortress will receive noble dwarves, such as a baron(ess) or a count(ess). The easiest way to create wealth is through workshops, though other resource-gathering is available. The population either grows from natural procreation or immigration.
The first thing you'll probably notice is that the game has an ASCII tile-set. If you're not used to ASCII games like NetHack, you might have a very hard time adapting. There are other tile-sets that are a little easier on the eyes. I personally don't mind the graphics so much as the limited view of the world. Many modern games use zoom mechanics to deal with complexity, but it isn't possible with Dwarf Fortress.
The game can be split into roughly three categories: building/mining/economy, combat, and history. I'll tackle the subjects one at a time to review the game
Dwarf Fortress keeps track of almost everything. The legends screens above about the dragon? One of those is created for each one of your dwarves, tracking the life events of the dwarf. Every sentient or large creature that your dwarf kills is tracked. Your dwarves can be happy, sad, or go crazy if their spouse dies. Baby dwarves can go insane if their parent dies. This, too, will be recorded.
The history system can be a bit overwhelming at times, but at the same time it feels as though the game you're playing has an epic quality to it. You're never forced to look at the history system, which I think is a big plus. Did a dragon just arrive at your fortress and take out half your population before one of your champions brought it down? You won't feel so bad after you look at the legend screen and find out that once upon a time that dragon killed the elven king.
However, if that dragon takes out your fortress, it is gone. Dwarf fortress is a one-way game with no mulligans. You can only pause the game and quit. You can never save the game, make a mistake, and then reload the game. If a dwarf dies, they're dead. This may make it difficult for some players, and if you like do-overs then this game probably isn't for you.
The combat system allows dwarves to train, equip specific weapons and shields, and become injured or die. The detail found in the history system also exists in the combat system. Axe-dwarves or sword-dwarves will lob off heads, while marks-dwarves (cross-bow wielders) will kill enemies by puncturing vital organs. You can find out (if you wish) that your marks-dwarf killed that fox by puncturing its spleen before the fox bleed out. Your soldiers will break bones that will take months to heal while doctors attend to them.
Overall the combat system is a nice balance to the economy, which I'll talk about below. One disadvantage with the system is that fights tend to be very one-sided. If a dragon shows up, your dwarves are either prepared or they're dragon-meat. There isn't really a delay-the-dragon-while-dwarves train option. Goblins will occasionally siege your fortress, which (again) isn't a problem if you're prepared.
Control with the combat system is probably the weakest link in the game. You can lump dwarves together into a squad, but if the squad leader is sleeping when the goblins attack you have to re-arrange the squad. I think it takes too long to re-arrange the military to respond to the threat. Controlling your civilians is also difficult; control is very coarse, only allowing you to shut off whether civilians or soldiers should stay underground. Additionally, civilians complain so much when they're forced to stay inside that it makes playing the game difficult during an attack. All you see is "civilian complains about going outside because civilian wants to do X." I think this area needs a little bit of work before the game can shine.
(above) Dwarves train in the barracks on the top left.
(above) Examining the wounds of a dwarf. The yellow text signifies a broken bone.
(above) Some goblins (purple and white 'g' characters) ambush and kill a bone carver (dead blue dwarf).
(above) An axe-wielding soldier (blue dwarf) is about to "axe"-xact revenge on the goblins.
(above) The goblins didn't have a chance.
I love building games like Sim City or Civilization. Dwarf Fortress has a great building system. You start by ordering dwarves to mine out an area of a mountain, creating a safe haven from the outside world. You then can create areas for stockpiles of resources, and workshops to turn the resources into either goods or other resources. A trade system exists with caravans to trade for goods. There is a complex assembly line for some goods - for example, to make steel armor, first you'll need steel bars. To get steel bars, a dwarf needs to process iron bars, a flux stone, and charcoal at a smelter. The charcoal needs to be produced at a wood furnace, and the flux stone needs to be mined from specific types of minerals. Charcoal is also used in other industries besides metal-smithing, such as glass-making, so to optimize the resource through-put you have to lay out your fortress stock-piles and workshops correctly.
Creating an effective economy is quite difficult. The distance to the surface of certain industries, such as the wood industry, needs to be balanced against fortress defense. Some structures, such as farms, have restrictions on what type of soil you can build them on top of. Your dwarves need to eat and sleep, but they'll have trouble sleeping near noisy workshops or eating near garbage.
When I first started playing the game I found myself thinking in 2-D...but over time, I realized that highly optimized fortresses needs to be built in 3-D. The extra dimension really adds a lot to the game if you love building assembly lines or working with resource management.
(above) Fields next to a river.
(above) Quarters with a bed and a door for about 100 dwarves. A set of nicer quarters with smoothed walls is in the middle
(above) A stock-pile of furniture on the left.
(above) A set of workshops spread across two rooms to the left of the hallway. There is a nearly empty stockpile of wood below one row of workshops (empty stockpiles are denoted by "=" signs).
(above) A dining room to the left of the hallway, with a garbage dump on the right. A row of workshops is below the garbage dump. The purple cloud is a miasma cloud coming from decomposing waste.
One of the most novel features of the game is the trap and pump system. You can pump water, and then use pressure plates to activate or deactivate flood-gates or pumps. If you want to build an auto-filling cistern or an underground irrigation system, you can set it up so you only have to pull a single lever to get your pumps and flood-gates to do what you want. Are you having trouble with goblins attacking your fortress? Placea puppy some food outside as bait and then drown the goblins when they step on a pressure plate. If you prefer to catch the goblin, use the plate to slam doors shut or just use an old-fashioned cage trap. You could build an arena and then have goblins fight to the death! Or maybe start a goblin breeding program and use the baby goblins as a source of totems.
The building system, I think, is the strongest feature of Dwarf Fortress. The possibilities are endless - whether you want to build an arena or figure out how to build a computer, the open-ended system is one of if not the best I've seen in a game.
Dwarf Fortress is an old school ASCII game with a lot of promise. If you can look past some of the rough edges with the combat system and incomplete features (the game is still an alpha), the game plays out like Sim City meets tinker toys. Much like Sim City, there is some dead-time while you wait for things to happen, but there is a great reward for building that auto-filling cistern. Overall if you liked NetHack and Sim City I think you'll love this game; but beware the high learning curve almost mandates using a guide to help you out with the first few steps.
The game has three modes: fortress, adventure and legend. All three modes center on different aspects of a single world - for the sake of brevity I'll be focusing solely on fortress mode, which is a mode similar to Sim City but with a fortress instead of a city. Adventure is a hack-and-slash mode similar to NetHack, and legend is an encyclopedic mode that is still in the works.
Two shots from legends mode show information a dragon that was slew in the year 118. If you like reading encyclopedias, you'll love legends mode!
The basic premise behind the game is all there in the title. You have dwarves, and you want to build a fortress in the side of a mountain (mountain optional). If you enjoyed playing Sim City, you'll probably enjoy Dwarf Fortress, though it has a *much* steeper learning curve. There isn't an end goal to the game, though as your fortress gains wealth and population your fortress will receive noble dwarves, such as a baron(ess) or a count(ess). The easiest way to create wealth is through workshops, though other resource-gathering is available. The population either grows from natural procreation or immigration.
The entrance to a fortress is shown at the left-hand side. There are two ballistas in the center-left defending the fortress entrance, along with two rooms straddling the entrance to allow cross-bow wielding dwarves to defend the entrance. On the right hand side of the screen is a bridge (red double-tildes with outline) crossing a brook (blue tildes). A dwarf is chilling on the bridge. The middle portion of the screen contains three catapults with ammo stock-piles to the left of them.
The first thing you'll probably notice is that the game has an ASCII tile-set. If you're not used to ASCII games like NetHack, you might have a very hard time adapting. There are other tile-sets that are a little easier on the eyes. I personally don't mind the graphics so much as the limited view of the world. Many modern games use zoom mechanics to deal with complexity, but it isn't possible with Dwarf Fortress.
The game can be split into roughly three categories: building/mining/economy, combat, and history. I'll tackle the subjects one at a time to review the game
History
Dwarf Fortress keeps track of almost everything. The legends screens above about the dragon? One of those is created for each one of your dwarves, tracking the life events of the dwarf. Every sentient or large creature that your dwarf kills is tracked. Your dwarves can be happy, sad, or go crazy if their spouse dies. Baby dwarves can go insane if their parent dies. This, too, will be recorded.
The history system can be a bit overwhelming at times, but at the same time it feels as though the game you're playing has an epic quality to it. You're never forced to look at the history system, which I think is a big plus. Did a dragon just arrive at your fortress and take out half your population before one of your champions brought it down? You won't feel so bad after you look at the legend screen and find out that once upon a time that dragon killed the elven king.
However, if that dragon takes out your fortress, it is gone. Dwarf fortress is a one-way game with no mulligans. You can only pause the game and quit. You can never save the game, make a mistake, and then reload the game. If a dwarf dies, they're dead. This may make it difficult for some players, and if you like do-overs then this game probably isn't for you.
Combat
The combat system allows dwarves to train, equip specific weapons and shields, and become injured or die. The detail found in the history system also exists in the combat system. Axe-dwarves or sword-dwarves will lob off heads, while marks-dwarves (cross-bow wielders) will kill enemies by puncturing vital organs. You can find out (if you wish) that your marks-dwarf killed that fox by puncturing its spleen before the fox bleed out. Your soldiers will break bones that will take months to heal while doctors attend to them.
Overall the combat system is a nice balance to the economy, which I'll talk about below. One disadvantage with the system is that fights tend to be very one-sided. If a dragon shows up, your dwarves are either prepared or they're dragon-meat. There isn't really a delay-the-dragon-while-dwarves train option. Goblins will occasionally siege your fortress, which (again) isn't a problem if you're prepared.
Control with the combat system is probably the weakest link in the game. You can lump dwarves together into a squad, but if the squad leader is sleeping when the goblins attack you have to re-arrange the squad. I think it takes too long to re-arrange the military to respond to the threat. Controlling your civilians is also difficult; control is very coarse, only allowing you to shut off whether civilians or soldiers should stay underground. Additionally, civilians complain so much when they're forced to stay inside that it makes playing the game difficult during an attack. All you see is "civilian complains about going outside because civilian wants to do X." I think this area needs a little bit of work before the game can shine.
(above) Dwarves train in the barracks on the top left.
(above) Examining the wounds of a dwarf. The yellow text signifies a broken bone.
(above) Some goblins (purple and white 'g' characters) ambush and kill a bone carver (dead blue dwarf).
(above) An axe-wielding soldier (blue dwarf) is about to "axe"-xact revenge on the goblins.
(above) The goblins didn't have a chance.Resources for the Economy
I love building games like Sim City or Civilization. Dwarf Fortress has a great building system. You start by ordering dwarves to mine out an area of a mountain, creating a safe haven from the outside world. You then can create areas for stockpiles of resources, and workshops to turn the resources into either goods or other resources. A trade system exists with caravans to trade for goods. There is a complex assembly line for some goods - for example, to make steel armor, first you'll need steel bars. To get steel bars, a dwarf needs to process iron bars, a flux stone, and charcoal at a smelter. The charcoal needs to be produced at a wood furnace, and the flux stone needs to be mined from specific types of minerals. Charcoal is also used in other industries besides metal-smithing, such as glass-making, so to optimize the resource through-put you have to lay out your fortress stock-piles and workshops correctly.
Creating an effective economy is quite difficult. The distance to the surface of certain industries, such as the wood industry, needs to be balanced against fortress defense. Some structures, such as farms, have restrictions on what type of soil you can build them on top of. Your dwarves need to eat and sleep, but they'll have trouble sleeping near noisy workshops or eating near garbage.
When I first started playing the game I found myself thinking in 2-D...but over time, I realized that highly optimized fortresses needs to be built in 3-D. The extra dimension really adds a lot to the game if you love building assembly lines or working with resource management.
(above) Fields next to a river.
(above) Quarters with a bed and a door for about 100 dwarves. A set of nicer quarters with smoothed walls is in the middle
(above) A stock-pile of furniture on the left.
(above) A set of workshops spread across two rooms to the left of the hallway. There is a nearly empty stockpile of wood below one row of workshops (empty stockpiles are denoted by "=" signs).
(above) A dining room to the left of the hallway, with a garbage dump on the right. A row of workshops is below the garbage dump. The purple cloud is a miasma cloud coming from decomposing waste.One of the most novel features of the game is the trap and pump system. You can pump water, and then use pressure plates to activate or deactivate flood-gates or pumps. If you want to build an auto-filling cistern or an underground irrigation system, you can set it up so you only have to pull a single lever to get your pumps and flood-gates to do what you want. Are you having trouble with goblins attacking your fortress? Place
The building system, I think, is the strongest feature of Dwarf Fortress. The possibilities are endless - whether you want to build an arena or figure out how to build a computer, the open-ended system is one of if not the best I've seen in a game.
Overall
Dwarf Fortress is an old school ASCII game with a lot of promise. If you can look past some of the rough edges with the combat system and incomplete features (the game is still an alpha), the game plays out like Sim City meets tinker toys. Much like Sim City, there is some dead-time while you wait for things to happen, but there is a great reward for building that auto-filling cistern. Overall if you liked NetHack and Sim City I think you'll love this game; but beware the high learning curve almost mandates using a guide to help you out with the first few steps.
2010-03-25
Tip About Airline Flights
On my recent trip from Amsterdam to Boston to Iowa to Amsterdam, I needed to move my last set of flights forward a day because of an important meeting. I called up American Airlines, and because my Boston to Iowa trip had been delayed, AA didn't charge any money to change my flight to Amsterdam.
If you ever need to reschedule flights, AA will be very accommodating if you've had previous delays. This is probably true for other airlines. I hope someone finds this tip as useful as I did.
If you ever need to reschedule flights, AA will be very accommodating if you've had previous delays. This is probably true for other airlines. I hope someone finds this tip as useful as I did.
2010-03-24
Grocery Stores in Iowa
How can any store carry hummus but not pita bread! They even had the extra garlic type of hummus.
Well, I guess that is Iowa for you. Sigh.
Well, I guess that is Iowa for you. Sigh.
2010-03-23
A Little Bit of Dancing
Congratulations to my big sister, who was married this weekend! There were some other photos that were shown at the wedding, but this one was my favorite; I think it sums up a lot of the past.
2010-03-11
California Iowa Here I Come
I'm on vacation for the next two weeks - woohoo! Looking forward to seeing you all.
2010-03-01
Sorry about Anonymous Commenting Being Turned Off
A loyal reader has informed me that anonymous commenting was turned off. My apologies, I've switched it back on.
2010-02-28
Trust in Giant Corporations
Nothing improves trust in a multi-national bank's online security quite as much as a directory listing for a home page.
2010-02-07
It's The Small Things
One reason I love VHDL is that the store operator isn't the equals sign:
Both lines of code instruct that if state_reg is equal to SHIFT, read_value should be incremented by next_value.
In C the = sign doesn't actually mean equals - that is what the == symbol means. In C, as in most programming languages, the = symbol really means "store the right-hand value into the variable." This caused me no end of confusion when I started programming - if you subtracted read_value from both sides of "read_value = next_value + read_value" wouldn't you get "0 = next_value?" In reality the line instructs the computer to add next_value to the current value of read_value, and store this sum back into read_value.
In VHDL = means equals and <= means store. Unfortunately <= also means less than or equal to. I would have preferred VHDL to use the symbol <- for store. In the first programming language I ever learned, TI-86 BASIC, there was a single-character symbol for <-. I still find the first line below to be the most intuitive of the three:
IF (SHIFT = state_reg) THENHere is some (nearly) equivalent code in C:
read_value <= next_value + read_value;
END IF;
if (SHIFT == state_reg) {
read_value = next_value + read_value;
}Both lines of code instruct that if state_reg is equal to SHIFT, read_value should be incremented by next_value.
In C the = sign doesn't actually mean equals - that is what the == symbol means. In C, as in most programming languages, the = symbol really means "store the right-hand value into the variable." This caused me no end of confusion when I started programming - if you subtracted read_value from both sides of "read_value = next_value + read_value" wouldn't you get "0 = next_value?" In reality the line instructs the computer to add next_value to the current value of read_value, and store this sum back into read_value.
In VHDL = means equals and <= means store. Unfortunately <= also means less than or equal to. I would have preferred VHDL to use the symbol <- for store. In the first programming language I ever learned, TI-86 BASIC, there was a single-character symbol for <-. I still find the first line below to be the most intuitive of the three:
sum <- element + sumI doubt programming languages will ever change from the equals sign to something else, but I would appreciate it. Every now and then my brain seems to go into math mode, and the = symbols still cause me confusion, but the <= is close enough to <- that I don't seem to notice. Oh well, maybe I'll never master C.
sum <= element + sum
sum = element + sum
2010-02-03
2010-01-26
Software Fail
My license is actually valid.
Just so you're aware, people use Xilinx FPGAs and the tool-chain for critical systems. I hope I'm not shaking your faith in that PET scanner, though. They're probably free from the issues associated with radiation therapy systems.
2010-01-19
The End of an Era
Tomorrow my @mit.edu account expires. It is about time, but I'll still miss it like crazy. The account was easily the best managed e-mail and file account I've ever had. I had over 12,000 messages in my inbox alone and nearly a gigabyte of files, capturing some of the best things I ever experienced, along with some of the most educational.
Farewell, account!
Farewell, account!
2010-01-07
Officially Old
With another birthday under my belt and the new year started, I am officially old. On the other hand, I've now been programming for more than 10 years! I dug up an old piece of my code, prime3b.java, which was last modified on July 14th, 1999. Technically, I've probably been programming for 12 or 13 years, but I don't think my self-taught, TI-86 programming should count as programming.
According to Wikipedia's Java Version Page, this program would have been created for Java 1.2. The program took a number, computed all the primes to that number, and could print out the calculated primes or number of primes.
PS In case you're wondering about my instructor's feedback, he said that one day I would be a superb programmer, after I had been crushed by the complexity of a few systems (I don't think he said "been crushed by", maybe "grappled with?"). This would teach me discipline, actions like encapsulating code into functions, thinking about testing, using standard formatting, using better variable naming, checking inputs, checking boundary conditions, and learning that code was also meant for people.
I'm still hoping his prediction comes true.
PPS I think most programmers fall into two categories: OCD programmers who need everything perfect, constantly re-visiting and re-working, orlazy efficient programmers who do the least amount of work even if it means more code. I think the above firmly puts a younger me into the efficient camp.
According to Wikipedia's Java Version Page, this program would have been created for Java 1.2. The program took a number, computed all the primes to that number, and could print out the calculated primes or number of primes.
import java.util.*;
public class prime3b
{
public static void main(String [] args)
{System.out.print("Would you like to print out all the primes?");
String cond = KeyBoard.readString();
boolean f = true;
boolean d = true;
if (cond == "no")
{f = !f;
}
System.out.print("Would you like to print out the number of primes?");
cond = KeyBoard.readString();
if (cond == "no")
{d = !d;
}
System.out.print("Enter a number:");
int x = KeyBoard.readInt();
int a = 0;
int b = 0;
int []m = new int [100000];
m[0] = 2;
int z = 0;
int e = 0;
int c = 3;
int y = 0;
long t1 = (new Date()).getTime();
for(; c <= x; c = c + 2)
{y = (int) Math.sqrt(c);
for(z = 0; m[z] <= y; z++)
{a = c % m[z];
if (a == 0)
{b = 1;
}
}
if (b == 0)
{e++;
m[e] = c;
}
else
{b = 0;
}
}
long t2 = (new Date()).getTime();
t2 = t2 - t1;
z = e;
if (f == true)
{for (; z != -1; z--)
{System.out.println(m[z]);
}
}
if (d == true)
{e++;
System.out.println("There were " + e + " primes at or below " + x);
}
System.out.println("Time is:" + t2);
}
}
PS In case you're wondering about my instructor's feedback, he said that one day I would be a superb programmer, after I had been crushed by the complexity of a few systems (I don't think he said "been crushed by", maybe "grappled with?"). This would teach me discipline, actions like encapsulating code into functions, thinking about testing, using standard formatting, using better variable naming, checking inputs, checking boundary conditions, and learning that code was also meant for people.
I'm still hoping his prediction comes true.
PPS I think most programmers fall into two categories: OCD programmers who need everything perfect, constantly re-visiting and re-working, or
Subscribe to:
Posts (Atom)