To a large degree, no, but the decisions made sense at the time. In retrospect, it would've made a lot more sense to offer to extend Steph's editor than starting from scratch, and I now know that the fact that it uses a different programming language would have been less of a hurdle than I thought at the time. I also likely would've looked into open source a lot earlier in retrospect. This is also something that could've been a lot more useful with a 2005 start - having an open source editor when there was lots of traffic could've encouraged its growth, and thus Civ's growth, even more - but we live and learn.
As for the technology itself, I feel that Java was a sensible choice, if perhaps not the optimal. The cross-platform aspect of it has really helped given that I haven't had a Mac for most of the development time, and thus it wouldn't have really been a cross-platform editor otherwise. The graphics (outside of the map itself, which is basically the same as Firaxis's editor) have perhaps aged the most - the editor has not taken kindly to the trend towards higher screen resolutions. As it is, the editor is using what's now the middle of the three main desktop Java graphics frameworks, though still a quite old one. However, the new one was still in its infancy in 2009, and had I chosen to go with it, I would've had to rewrite the graphics to keep it running on modern systems. So I think I made the right choice of graphics frameworks, but I didn't make good use of the abilities it does have to play nice with variable-resolution monitors.
I've also learned a lot about coding in the past 6-7 years. When I started, and wrote most of the code, I was still an amateur and a student. I'd worked on long-term group projects a bit, but this soon became the largest project I'd work on in code size, and still would be until about a year after the initial release. I learned more about source control though it, as well as modularization - a lesson that was forced by hitting a (quite reasonable) limit in the language while developing. There's a lot of places where I'd code in a different style now as well. There's code like this:
Code:
else if (terrainType < 14) //not sea/ocean - is base terrain
{
boolean wasLandmark = (tile.C3CBonuses & 0x2000) == 0x2000;
if (brush.isLandmark)
tile.C3CBonuses = tile.C3CBonuses | 0x2000;
else
tile.C3CBonuses = tile.C3CBonuses & ~0x2000;
//Deepwater harbour
//This is essentially a hack - we can't use our standard calculations about
//whether to allow the terrain modification or not.
if (terrainType == 12 && brush.isDeepwaterHarbour)
{
if (tile.getBaseTerrain() == 11) //was coast; valid harbour
{
Which works, but involves a lot of low-level manipulation (sometimes spread out across files) and magic numbers. Not very maintenance-friendly, and that became a bit of a pain when trying to add PTW and Vanilla support. But those are things that I think of now, but didn't think of nearly as much in 2010 (or even, apparently, 2013, when that particular code was written).
A lot of that old code is going to stay, though. It's a lot of mostly-uninteresting work to change it, and it does pretty much work. If you wonder why banks still use software from the '60s and '70s in some cases, this is basically why, with the complication that sometimes they've lost the source code. The perfectionist in me wants to correct them, but when I actually start working on them I realize the features are way more fun, and thus the case usually is that only the ones that make creating the features a pain actually get changed.