I have been a hobbyist programmer for a very long time. I have experience with many programming languages, beginning from 6502 machine language and BASIC on my old Commodore 64. Through the years Iíve done personal projects with C, C++, C# and most recently Python. I also have a funny story about a job I had using an old DOS language called Clarion, but that is not relevant to this portfolio, as the comedic section of this document will be found in my rťsumť.
Since late 2007, Iíve been active in the Civ4 modding community making map scripts for the game and some fan made mods. To make these scripts I learned the Python programming language, and Iíve really grown to appreciate its ease of use and low cost. Since I started with Civ4 maps Iíve used Python on many different personal side projects.
Procedural game content creation is something that I am very interested in, and I have spent much of my adult life thinking about how it can be utilized in games. I think of it as a tool, like an artistís paintbrush, that if used with skill and good taste can create beautiful results. The setting of a full game of Civilization begins at a time when mankind had little or no understanding of the world over the next hill, and for that reason, the game begins with most of the map obscured from the eyes of the player. To capture that sense of discovery, the game is best when the player is playing on a map that he has never seen before. Civ4 allows players to create and share pre-made maps, but a well made map script can easily deliver a nearly limitless number of unknown worlds to explore. A big part of the game is exploration, and you lose that if you already know what the map looks like.
PerfectWorld was my first Civ4 map script and the one in which I have invested the most time and energy. I'm happy to say it has become very popular with more than 17,000 downloads at the time of this writing. The map scripts that came with the original Civ4 release were unsatisfying to me. They werenít bad, but it was clear that this aspect of the game was purely functional. The maps allowed you to play Civ on them. While watching the ďMaking of Civ4Ē DVD, because Iím the kind of geek who watches that kind of stuff, I listened to Soren Johnson, the lead designer, explain that they didnít want the map to be the focus. The units are what the player interacts with, and obsessing over the map was bogging them down.
It was a logical argument, but I couldnít quite get myself to agree with it. Players interact with the units, but the map is what they are looking at most in any game session. This is the setting of the story that unfolds. Itís very, very important, even if itís not the most important thing existing on the screen at a given moment.
I felt like I could add some drama and storytelling to the world map that would enhance the game, so I resolved to give the map all the attention I felt it may have lacked. My goals were to make a map that was entirely unpredictable, challenging to play on by forcing strategic choices on the player, and every bit as beautiful as any artist could make by hand. It needed to be all of this every time the map was generated. You canít let a player waste a half hour only to discover heís playing on a broken map. It has to be good every time.
These are lofty goals, but I had faith that if I did my best to simulate the real Earth, everything would naturally fall into place. Iím no geologist and Iím no meteorologist, but by adhering to some simple common knowledge regarding the forces that shape the Earth, even if the simulation was not entirely accurate, it helped to give the map a sense of believability. At first it may appear that I didnít have much to work with, peaks, hills and flat land with a few terrain types and some foliage types, but when taking all the possible combinations together, I could in fact convey a great deal of information that didnít exist before. Even when you canít see it directly, you can feel it, and believe in it.
All this simulation of climate and landforms made the map look very nice, but it was also obvious that the game was not designed to be played on a map like this. A lot of extra work had to go into making the map playable and fun. Finding player starting positions that were remotely fair was a huge challenge on this map. One of the characteristics of the stock maps, and one of the reasons I didnít like them so much, was that terrain was scattered haphazardly in a fairly homogenous way. The algorithms that placed the starting locations didnít have to be terribly thorough. As long as a player had land to expand into, the land was likely to have a variety of terrain in close proximity that they could build cities with.
This was not the case in PerfectWorld! There were frequently vast deserts and tundra to contend with. A small green valley might be a paradise for a starting city, but if itís separated from the rest of the habitable world by a stretch of sand larger than the Sahara, then itís not a good starting position. Possibilities like these need to be recognized and dealt with, and there is a lot of code in PW to deal with just that one problem.
Almost every aspect of map generation had to be overridden to accommodate my goals, but in the end I think it was worth it. Itís been a lot of fun listening to the compliments and feedback. People tell me very often that PerfectWorld injects new life into Civ4 and that is of course very satisfying to hear. Iím very grateful to Firaxis for making such a great, and moddable game. Iíve had more than my share of fun with it. Follow this link to download the .py file from Civfanatics.
I originally created this map script under the name ĎCreationí for ďFall from Heaven IIĒ Derek Paxtonís well known and admired fantasy mod for Civilization IV. At some point Derek decided he really liked this script and made it the official map script for FfH2, at which time the name was changed to ĎErebusí to reflect the name of the gameís setting.
My goals for this map script were to increase the drama and get away from the Ďplanetí type maps that are used for a typical game of Civ, and change the scale of the game map from the whole world to only a part of it. In fantasy worlds, it is common for the story to take place at a time when there is a great deal of mystery left in the world, and the characters of the story are concerned with only the realms that are known to them. Outside of this are only wild and dangerous areas of little use to any civilized creature. Fantasy worlds often have distinct regions or valleys that have their own special climate or atmosphere. Some examples would be Mordor from LOTR, or most of the regions in World of Warcraft. This map script is designed to emulate this trend and has various 'valleys' connected to one another through mountain passes, such that each region is kind of a fortress on its own. The terraforming options in FfH really augment this basic structure. As many factions are able to shape the climate to their preference, it often becomes very clear who owns what valley.
The source code for the original Creation map script can be downloaded here and can be used for unmodified Civ4. The Erebus map script is now only compatible with FfH2 and is included in the download for the mod.
The Spiral Galaxy map script is something I cooked up for the Civ4 mod Final Frontier. Final Frontier is a space based mod and one of the official mods that come with the expansion pack Beyond the Sword. The default map is just random space features on a rectangle that wraps toroidally in both directions. I thought it would be fun to lay down some rules, and it seemed an obvious choice to make a spiral galaxy. It was through this map that I learned how to draw a logarithmic spiral, courtesy of Wikipedia!
The FaireWeather map script was made for the game Civilization IV: Colonization made by Firaxis and based on the Civ4 engine. The game came with a single map script that was similar in function to some of the map scripts that came with the original release of Civ4, and many people were not happy with it. In the years between Civ4 and Civ4:Col, many map scripters, myself and others, had been busy raising the bar of expectations for what a Civ4 map should accomplish, and it was clear that this Ďback to basicsĎ map script needed a replacement.
I anticipated this, and redesigned much of my PerfectWorld code from scratch over the months prior to Cols release. I was able to present a nice new PerfectWorld style map in the first week after the games release. It improves the atmosphere of the game a great deal, and if youíre going to play Col you should really use FaireWeather.
This new map had many improvements in speed and accuracy over the original PerfectWorld, and so I used the FaireWeather map engine as a basis for PerfectWorld2 to replace the original. The example I gave earlier is actually PerfectWorld2, the latest in that line.
The Arrakis map script is a work in progress designed to work with the ĎDune Warsí Civ4 mod currently in development over at Civfanatics. Itís a mod that takes place in Frank Herbertís Dune universe. Iím pretty excited about this mod. There are some really good modders who joined this effort recently and development is moving along very well at the time of this writing.
When I was asked to make a map script for this mod, I was intrigued because it would certainly require a very different kind of map. At first I thought, ďJeez, thereís nothing on Arrakis but sand. This will be the easiest map script Iíve done yet!Ē However, the challenge on an Arrakis map is to try and make something out of a whole lot of nothing.
After some research on the Dune universe, I learned that the only habitable area on Arrakis is a little area around the north pole. Everything south of 60 degrees is battered by 300 mph winds. So this map is centered on top of the north pole. Instead of having plain old flat desert in the outlying areas, I spiced things up a bit (Uh oh, Dune pun) by adding a dune pattern. I accomplished this by creating a sand ripple texture, converting it to a stream of numbers that I copied and pasted into the script, and superimposing this texture over any desert that was far enough away from the rocky areas. Depending on the texture value, I change the altitude of the desert to create dunes. That makes what would be featureless desert a little more fun I think.
I did it! After many years of abortive attempts I finally finished a game from top to bottom, all by myself. Front Line is a simple, conquer-the-world strategy game. The game was written in C# for the Microsoft .NET 1.1 framework. All of the programming, graphics (programmer art), sound engineering and original music were created by me.
I learned a lot of lessons during this project. I worked very hard on this but I did not work smart. There is no game engine here, no DirectX, itís all done with GDI+ and the Native Windows API. If you are going to make a game by yourself this is not the way to do it. Part of the reason I did this game with GDI+ was to promote my crazyforms.dll project, which was a window Ďskinningí system I had designed previously for use with .NET. It was similar to Stardockís ĎWindow Blindsí but for a single application.
In spite of the ups and downs, I am very proud of this achievement. It really is a fun little game, and I still play it from time to time. Iím especially happy with the victory song I wrote. Itís a snappy little fife and drum piece if there ever was one. The only way to hear it howeverÖ is to win the game!
Here is the download for the full version. But there are a couple of things to beware of.
I donít know what the system requirements are, but they are kind of high. Built in, minimal graphics cards tend to cause a crash midgame. The GDI+ API from .NET 1.1 crashes with no descriptive error message when it runs out of resources, and I didnít learn about this until a year or so after the game was released. This problem is greatly compounded by the fact that there is no autosave in the game! Unforgivable in a game that was released in 2006! Sorry, sorry, sorryÖ Save often please.
Also, in the help menu there is a link to a manual that no longer exists. This is the lesson I learned about hard coded URLís. You can get the manual from this link. Bookmark it for easy reference. The game is fairly simple, but you still need the manual to understand some of its key concepts. I recommend reading this one page manual all the way through before playing.
CrazyForms is a window skinning system I designed that allowed a Windows .NET program to have it's own unique style. You can download the demo here. There is no installation, just click on the .exe. To set up a window dressing, open the editor window and from there open a .cff file. Then go back to the main window and select 'Use Window Dressing' to enable the new style. Some of these are animated and look better in real time.
This is one of my earliest completed projects and I think it is pretty interesting. I wrote this in 1995 in pure assembly language, because that was the only programming language I knew at the time. Its not very often that programmers start learning with assembly, but when you are starting in the C64 era, and the only alternative is the slow as molasses C64 BASIC, you do what you have to do.
This program simulates a defined galaxy of around 3 billion star systems. Itís important to state that this is not a random galaxy. This is the very same galaxy as it has ever been since 1995. It is a procedural galaxy, not a random galaxy. Each of the star systems has some number of planets, and each planet has itís own unique topographical map.
This program is still runnable on windows XP, but Vista requires DOS emulation. Thereís no timer control so DOS emulation is always helpful to keep this thing under control on modern computers. If you want to give it a try download it here.
The interface has three different screens. The first screen is a view of a 3D portion of the galaxy. For simplicity's sake, this galaxy is actually shaped like a big flat box divided into sectors. It is 8192 x 8192 x 64 sectors large and is about evenly dense throughout the box. There is a little direction vane in the bottom corner that can be used to scroll through the galaxy in three dimensions. Putting the mouse cursor on a star will show you how many planets are in that star system and clicking on the star will take you to the system screen.
The second screen is a view of the planets and their relative sizes. If there are too many planets to fit on one screen, a scroll button will appear in the top corner to flip through as many planet screens as necessary. Pointing to a planet with the mouse will indicate whether a planet has a topographical map associated with it. My thinking, at the time, on this was that a planet that was above a certain size would have a gravitational pull that was too strong to have topographical features. I reasoned that there was no point in generating a smooth surface. In terms of presentation, I realize this was probably a mistake because it makes the user have to work a little too hard to find topographical maps to look at, due to the large number of supersize planets.
By clicking on the appropriate planet, we come to the third screen, which is the map screen. clicking anywhere on this screen other than the galaxy map button will bring you back to the planets screen. For simplicity's sake, I only created five types of planets according to their size: asteroid type, moon type, mars type, earth type(with oceans), and larger than earth type with a green hazy atmosphere. I reasoned that, since all the planets are unique, the value of this technique would be easy to grasp. What I have found though, is that people tend to get stuck on the fact that there are only five types of planets. In gameplay terms, it means nothing that the planets are unique because planets of the same type are so similar to each other, they may as well be exactly the same. As is, this program would not make an interesting universe to explore in a game. What I have to do every time I show this program, is to explain that I chose five distinct types for simplicity only, and that with a little more work, I could have also created a range of types instead of distinct types, depending on certain variables such as: sun size, distance from sun, planet size, tidal forces, geologic makeup, radiation levels, etc.