Score one for the good guys

I’d like to thank everybody on the forums who helped out in the investigation, and I hope this can be a lesson to greedy bot authors everywhere.

HUGE UPDATE: Read my updated article and wotc’s official statement. Great work, wotc, for your willingness to investigate this matter, and thanks to everybody who helped prove this scam. Continue Reading »

I have always used Quicken for the most minimalistic of checkbook balancing. For some reason, even though the newer versions have continued to get bigger and more bloated, I’ve continued to stick with them, and even paid for the pile of rat dung they call Quicken Deluxe 2005.

Hating Intuit was a dangerous choice, as it turns out. Starting in 2005 editions, Intuit apparently added in the ability to disable select features after a three year period. For those of us who rely on, say, importing transactions from our bank, we’re just screwed through and through. Raped, more like. Violently. With broomsticks, chains, whips, and random jolts of high-voltage electricity.

How can a company as big as Intuit actually get away with something like this? It’s pretty much blackmail - won’t their users get as disgusted as I did and look for other options?

…

Maybe it doesn’t even matter. Because I did that. I looked at the other options. I looked at Moneydance. I looked at Gnucash. I looked at a few others whose names I forgot about as fast as it took me to run their uninstall programs. I avoided MS Money because I’ve heard it’s just as bad as Quicken in terms of the BS they’ve added in over the years.

In the end, I wasted a couple hours just to buy Quicken 2008.

I’m amazed at how utterly shitty the competition is. I’m a software designer for a living, and I’ve even worked on accounting software at my last job, so I know how challenging it can be to design something as big as a knock-off of a really successful accounting package. And for the freeware options, I can hardly fault them for sucking - they’re free. Gnucash looks promising if you’re an accountant. Plus, it couldn’t deal with downloaded transactions even a tenth as nicely as Quicken. Moneydance, a commercial app, was written wholly in Java, making its UI anything but consistent with other Windows apps. Plus, it couldn’t deal with downloaded transactions even as well as Gnucash. Another app, another set of problems, plus they couldn’t fucking deal with downloaded transactions nicely.

I can’t figure it out. For all of Intuit’s crap, for all Quicken’s painful UI decisions, it’s still the best app for somebody who just wants to download transactions and keep a single checking account balanced. Weird.

I’m sure I’ve bitched about open source plenty of times, but I have to rant once again. Dotproject is my project management application of choice. It does everything I want, and in particular allows for very awesome time estimation which was extremely useful for Bloodsport Colosseum. I was able to break down every task into subtasks and really get a feel for how much effort was left by looking at the accuracy of past estimates.

But it’s programmed by idiots. I mean, these guys are actually pretty stupid compared to the average rock. I’m sorry, it’s a great tool designed by somebody who had a head for project management, but programmed by idiots.

After not using dotproject for a while (after the death of bloodsport colosseum, I had little to track), I got a contract job that really needs careful design. So I jumped back into a semi-recent version of this awesome/disgusting app, and found that it uses overlib for popup help! (No, that isn’t the problem. Overlib is actually really nice for web-based hover-help) But the dotproject devs by default chose to make the popups STICKY. That is, when you hover over a link you think is just a link, a popup shows up that will not go away until you explicitly mouse over the “close” button.

This is revolting.

So I know overlib. I’m not phased a bit. I used it for Bloodsport Colosseum and it’s really a pretty straightforward JS library (a rarity these days). It’s open source, so it probably sucks monkey balls, but as a user of the tool, I liked it.

Overlib has a central area to put all your app’s default preferences for things like font, colors, opacity, and, of course, sticky. To override the defaults, you can actually specify “commands” in your call to the overlib methods, which is handy for special cases.

The dotproject dimwits actually ignored the defaults altogether, and put the exact same preferences into their HTML in seven different places. I’m not sure what can happen to a programmer where they learn the number one failing of software. The first thing you learn in your first CS class is about code reuse. Functions, code centralization, that sort of shit. HOW can somebody be so stupid as to ignore these amazingly simple principles when the library already provides a really easy and central place for this stuff?

Then I remembered my first dotproject disaster - an old version had some broken SQL for calculating the % left on a task, and to fix it I had to change this SQL in 3 or 4 places, and rewrite a couple rather large sections of code.

No, that memory didn’t comfort me, but at least I was able to say, “Oh yeah, they’re just dotproject developers. They didn’t know better.”

I can’t believe this. Simply amazing.

I really can’t.

I’m not even sure this is good enough to fall under my usual “Awesome Software Discovery” banner.

So I work at a place where we use Ruby and Perl a lot, right? The above site is supposedly a “conversion” of O’Rielly’s Perl Cookbook into Ruby. Good idea. But here’s the thing - if you don’t know your ass from a hole in the ground, maybe you shouldn’t be writing a programming guide. Maybe. I don’t know. Am I being too harsh?

The introduction shows this example:

# $defout (or its synonym '$>') is the destination of output
# for Kernel#print, Kernel#puts, and family functions
logfile = File.new("log.txt", "w")
old = $defout
$defout = logfile                 # switch to logfile for output
puts "Countdown initiated ..."
$defout = old                     # return to original output
puts "You have 30 seconds to reach minimum safety distance."

There is no fucking excuse for this kind of programming style. Even a total noob should look at this and say, “What the fuck?”

1. Yes, sometimes you need to redirect output or errors to a file… but the introduction doesn’t explain that this is an exception rather than a rule.
2. Redirecting $defout is very dangerous if the developer doesn’t fully understand 100% of what they’re writing, and the libraries they’re using. (And if they need a perl-to-ruby cookbook, chances are they don’t understand 100% of what they’re writing)
3. Maybe I’m misreading something, but isn’t it significantly safer in an app more than 3 lines long to call .dup on $stdout / $defout when saving the old value? (The answer is “yes,” for my less astute readers)

In any case, here’s how you write to a file in Ruby without making the guy who reviews your code cringe and then stab you in the fucking eye (note that it’s not only safer, but also easier to read and generally doesn’t make you look like a moron):

# $defout, $stdout, and other magic variables are NOT TOUCHED!
logfile = File.new("log.txt", "w")
logfile.puts "Countdown initiated..."
puts "You have 30 seconds blah blah I'm a monkey licker."

Neat!

It seems that the once-monopolistic domain registrar, Network Solutions, has decided they need more power again. Domain Name Wire’s article reads like a bizarre April Fool’s joke at first glance, but it’s true. I tried it out with sweettemplatesforphp.com just for kicks, and those bastards really did park the domain.

Their motives almost seem genuine: “This is a customer protection measure to protect customers from frontrunners. After four days, we release the domain.” says Network Solution’s spin doctor PR spokeswoman, Susan Wade.

But if this is truly their goal, why is there no mention of it when you do a search? Why is there no option to skip it? Why the hell isn’t there a giant blinking warning? “IF YOU SEARCH FOR A DOMAIN WE’LL F*CKING SNAG IT FOR FOUR DAYS SO YOU CAN’T SHOP AROUND!”

I get it that they aren’t forcing you to pay a premium to register the domain from them. They’re just “safeguarding” it from the real front runners. But the thing is, they’re guaranteeing that if I do a search for a domain, I can not shop around for prices without going through this BS waiting period. A much more elegant solution (if they really want one, which I suspect they do not) would be a little checkbox:

If it takes me two minutes to come up with a solution that isn’t controversial, it can’t be that hard….

Sloccount is my newest Awesome Software Discovery. It’s a great idea, but is far too simple to do what it claims: estimate effort and expense of a product based on lines of code. And really, I wouldn’t expect it to be that great. The model used to estimate effort is certainly not the author’s fault, as it isn’t his model. But that idiot (David Wheeler) doesn’t just say it’s a neat idea - he actually uses this horrible parody of good software to “prove” that linux is worth a billion dollars. For the record, I prefer linux for doing any kind of development. I hate Windows for development that isn’t highly visual in nature (Flash, for instance kind or requires Win or Mac), and Macs are out of my price range for a computer that doesn’t do many games. So Linux and I are fairly good friends. I just happen to be sane about my liking of the OS. (Oh, and BSD is pretty fracking sweet, too, but Wheeler didn’t evaluate it, so neither will I)

The variables

To show the absurdity of sloccount, here’s a customized command line that is assuming pretty much the cheapest possible outcome for a realistic project. The project will be extremely easy for all factors that make sense in a small business environment. We assume an Organic model as it is low-effort and most likely situation for developing low-cost software.

Basically I’m assuming a very simple project with very capable developers. I’m not assuming the highest capabilities when it comes to the dev team because some of that stuff is just nuts - the whole team on a small project just isn’t likely to be having 12+ years experience, and at the top 10% of all developers. But the assumptions here are still extremely high - team is in the top 75% in all areas, and 6-12 years of experience, but pay is very low all the same. This should show a pretty much best-case scenario.

Also, I’m setting overhead to 1 to indicate that in our environment we have no additional costs - developers work from home on their own equipment, we market via a super-cheap internet site or something (or don’t market at all and let clients do our marketing for us), etc.

Other factors (from sloccount’s documentation ):

• RELY: Very Low, 0.75
  • We are a small shop, we can correct bugs quickly, our customers are very forgiving. Reliability is just not a priority.
• DATA: Low, 0.94
  • Little or no database to deal with. Not sure why 0.94 is the lowest value here, but it is so I’m using it.
• CPLX: Very Low, 0.70
  • Very simple code to write for the project in question. We’re a small shop, man, and we just write whatever works, not whatever is most efficient or “cool”.
• TIME: Nominal, 1.00
  • We don’t worry about execution time, so this isn’t a factor for us. Assume we’re writing a GUI app where most of the time, the app is idle.
• STOR: Nominal, 1.00
  • Same as time - we don’t worry about storage space or RAM. We let our users deal with it. Small shop, niche market software, if users can’t handle our pretty minimal requirements that’s their problem.
• VIRT: Low, 0.87
  • We don’t do much changing of our hardware or OS.
• TURN: Low, 0.87
  • I don’t know what this means, so I’m assuming the best value on the grid.
• ACAP: High, 0.86
  • Our analysts are good, so we save time here.
• AEXP: High, 0.91
  • Our app experience is 6-12 years. Our team just kicks a lot of ass for being so underpaid.
• PCAP: High, 0.86
  • Again, our team kicks ass. Programmers are very capable.
• VEXP: High, 0.90
  • Everybody kicks ass, so virtual machine experience is again at max, saving us lots of time and money.
• LEXP: High, 0.95
  • Again, great marks here - programmers have been using the language for 3+ years.
• MODP: Very High, 0.82
  • What can I say? Our team is very well-versed in programming practices, and make routine use of the best practices for maintainable code.
• TOOL: Very High, 0.83
  • I think this is kind of a BS category, as the “best” system includes requirements gathering and documentation tools. In a truly agile, organic environment, a lot of this can be skipped simply because the small team (like 2-3 people) is so close to the codebase that they don’t have any need for complexities like “proper” requirements gathering. Those things on a small team can really slow things down a lot. So I’m still giving a Very High rating here to reflect speedy development, not to reflect the grid’s specific toolset. For stupid people (who shouldn’t even be reading this article), this biases the results against my claim, not for it.
• SCED: Nominal, 1.00
  • Not sure why nominal is best here, but it’s the lowest-effort value so it’s what I’m choosing. Dev schedules in small shops are often very flexible, so it makes sense to choose the cheapest option here.

So our total effort will be:

0.75 * 0.94 * 0.70 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 0.86 * 0.91 * 0.86 *                # VIRT - PCAP
0.90 * 0.95 * 0.82 * 0.83 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

= 0.33647 effort

We’re also going to assume a cheap shop that pays only $40k a year to programmers, because it’s a small company starting out. Or the idiot boss only pays his kids fair salaries. Or something.

Command line:

sloccount --overhead 1 --personcost 40000 --effort 0.33647 1.05

Bloodsport Colosseum

For something simple like Bloodsport Colosseum, this is an overly-high, but acceptable estimate. With HTML counted, the estimate is 5.72 man-months. Without, it’s 4.18 man-months. We’ll go with the average since my HTML counter doesn’t worry about comments, and even with rhtml having embedded ruby, the HTML was usually easier than the other parts of the game. So this comes to 4.95 months. That’s just about 21 weeks (4.95 months @ 30 days a month, divided by 7 days a week = just over 21). At 40 hours a week that would work out to 840 hours. I spent around 750 hours from start (design) to finish. I was very unskilled with Ruby and Rails, so this estimate being above my actual time is certainly off (remember I estimated for people who were highly skilled), and a lot of the time I spent on the project was replacing code, not just writing new code. But overall it’s definitely an okay ballpark figure.

When you start adding more realistic data, though, things get worse.

If you simply assume the team’s capabilities are average instead of high (which is about right for BC), things get significantly worse, even though the rest of the factors stay the same:

0.75 * 0.94 * 0.70 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 1.00 * 1.00 * 1.00 *                # VIRT - PCAP
0.90 * 0.95 * 0.82 * 0.83 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

= 0.4999 effort

This changes our average from 4.95 man-months to 7.3 months, or about 31 weeks. That’s 1240 hours of work, well more than I actually spent. From design to final release, including the 1000-2000 of lines of code that were removed and replaced (ie, big effort for no increase in LoC), I spent about 40% less time than the estimate here.

…And for the skeptics, no, I’m not counting the rails-generated code, such as scripts/*. I only included app/, db/ (migration code), and test/.

However, this still is “close enough” for me to be willing to accept that it’s an okay estimate. No program can truly guess the effort involved in any given project just based on lines of code, so being even remotely close is probably good enough. The problem is when you look at less maintainable code.

Just for fun, you can look at the dev cost, which is $21k to $28k, depending on whether you count the HTML. I wish I could have been paid that kind of money for this code….

Murder Manor

This app took me far less time than BC (no more than 150-200 hours). I was more adept at writing PHP when I started this than I was at writing Ruby or using Rails when I started BC. But the overall code is still far worse because of my lack of proper OO and such. So I tweak the numbers again, to reflect a slightly skilled user of the language, but worse practices, software tools, and slightly more complex product (code was more complex even though BC as a project had more complex rules. Ever wonder why I switched from PHP for anything over a few hundred lines of code?):

0.75 * 0.94 * 0.85 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 1.00 * 1.00 * 1.00 *                # VIRT - PCAP
0.90 * 0.95 * 1.00 * 1.00 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

WHOA. Effort jumps to 0.8919! New command line:

sloccount --overhead 1 --personcost 40000 --effort 0.8919 1.05

This puppy ends up being 3.4 months of work. That’s 14.5 weeks, or 580 hours of work — around triple my actual time spent!

Looking at salary info is something I tend to avoid because as projects get big, the numbers just get absurd. In this case, even with a mere 3500-line project, the estimate says that in the environment of cheap labor and no overhead multiplier, you’d need to pay somebody over $10k to rewrite that game. Good luck to whatever business actually takes these numbers at face value!

But these really aren’t the bad cases. Really large codebases are where sloccount gets absurd.

Big bad code

Slash ‘em is a great test case. It isn’t OO, is highly complex, and has enough areas of poor code that I feel comfortable using values for average- competency programmers. So here are my parameters, in depth:

• RELY: Very Low, 0.75
  • Free game, so not really any need to be highly-reliable.
• DATA: Nominal, 1.00
  • The amount of data, in the form of text-based maps, data files, oracle files, etc. is pretty big, so this is definitely 1.00 or higher.
• CPLX: Very High, 1.30
  • Complex as hell - the codebase supports dozens of operating systems, and has to keep track of a hell of a lot of data in a non-OO way. It’s very painful to read through and track things down.
• TIME: High, 1.11
  • Originally Nethack was built to be very speedy to run on extremely slow systems. There are tons of hacks in the code to allow for speeding up of execution even today, possibly to accomodate pocket PCs or something.
• STOR: Nominal, 1.00
  • I really can’t say for sure if Slash ‘Em is worried about storage space. It certainly isn’t worried about disk, as a lot of data files are stored in a text format. But I don’t know how optimized it is for RAM use - so I choose the lowest value here.
• VIRT: Nominal, 1.00
  • Since the app supports so many platforms, this is higher than before. I only chose Nominal because once a platform is supported it doesn’t appear its drivers change regularly if at all.
• TURN: Low, 0.87
  • Again, I don’t know what this means, so I’m assuming the best value on the grid.
• ACAP: Nominal, 1.00
  • Mediocre analysts
• AEXP: Nominal, 1.00
  • Mediocre experience
• PCAP: Nominal, 1.00
  • Mediocre programmers
• VEXP: Nominal, 1.00
  • Okay experience with the virtual machine support
• LEXP: Nominal, 1.00
  • Mediocre language experience
• MODP: Nominal, 1.00
  • The code isn’t OO, which for a game like this is unfortunate, but overall the code is using functions and structures well enough that I can’t really complain about a lot other than lack of OO.
• TOOL: Nominal, 1.00
  • Again, nominal here - the devs may have used tools for developing things, I really can’t be sure. I know there isn’t any testing going on, so I can be certain that 1.00 is the best they get.
• SCED: Nominal, 1.00
  • The nethack and slash ‘em projects are unfunded, and have never (as far as I can tell) worried about a release schedule. Gotta choose the cheapest value here.

Total:

0.75 * 1.00 * 1.30 * 1.11 * 1.00 *                # RELY - STOR
0.87 *                                            # TURN (the rest are 1.00)
2.3                                               # Base organic effort

Total is now 2.166 effort. New command line, still assuming cheap labor and no overhead:

sloccount --overhead 1 --personcost 40000 --effort 2.166 1.05

Slash ‘Em is a big project, no doubt about it. But the results here are laughable at best. The project has 250k lines of code, mostly ansi c. The estimate is that this code would take nearly 61 man-years of effort. The cost at $40k a year would be almost $2.5 million! With an average of just under 24 developers, the project could be done in two and a half years.

I worked for a company a while ago that built niche-market software for the daycare industry. They had an application that took 2-3 people around 5 years to build. It was Visual C code, very complex, needed a lot more reliability than Slash ‘Em, was similar in size (probably closer to 200k lines of code), and had a horrible design process in which the boss would change his mind about which features he wanted fairly regularly, sometimes scrapping large sections of code. That project took at most 15 man-years to produce. To me, the claim that Slash ‘Em was that much bigger is a great reason to make the argument that linux isn’t worth a tenth what Wheeler claims it is. Good OS? Sure. But worth a billion dollars??

Linux and the gigabuck

I’m just not sure how anybody could buy Wheeler’s absurd claim that Linux would cost over a billion dollars to produce. Sloccount is interesting for sure, particularly for getting an idea of one project’s complexity compared to another project. But using the time and dollar estimates is a joke.

Wheeler’s own BS writeup proves how absurd his claims are: Linux 6.2 would have taken 4500 man-years to build, while 7.1, released a year later, would have taken 8000 man-years. I’m aware that there was a lot of new open source in the project, and clearly a small team wasn’t building all the code. But to claim that the extra 13 million lines of code are worth 3500 years of effort, or 400 million dollars…. I dunno, to me that’s just a joke.

And here’s the other thing that one has to keep in mind: most projects are not written 100% in-house. So this perceived value of Linux due to the use of open source isn’t exclusive to Linux or open source. At every job I’ve had, we have used third-party code, both commercial and open source, to help us get a project done faster. At my previous job, about 75% of our code was third-party. And in one specific instance, we paid about a thousand dollars to get nearly 100,000 lines of C and Delphi code. The thing with licensing code like this is that the company doing the licensing isn’t charging every user the value of their code - they’re spreading out the cost to hundreds or even thousands of users so that even if their 100k lines are worth $50k, they can license the code to a hundred users at $1000 a pop. Each client pays 2% of the total costs - and the developmers make more money than the code is supposedly worth. And clearly this saves a ton of time for the developer paying for the code in question.

If you ignore the fact that big companies can use open source (or commercially-licensed code), you can conjure up some amazing numbers indeed.

I can claim that Bloodsport Colosseum is an additional 45 months of effort simply by counting just the ruby gems I used (action mailer, action pack, active record, active support, rails, rake, RedCloth, and sqlite3-ruby). Suddenly BC is worth over $175k (remember, labor is still $40k a year and I am still assuming a low-effort project) due to all the open source I used to build it.

Where exactly do we draw the line, then? Maybe I include all of Ruby’s source code since I used it and its modules to help me build BC. Can I now claim that BC is worth more than a million dollars?

Vista is twice as good as Linux!

As a final proof of absurdity, MS has a pretty bad track record for projects taking time, and the whole corporate design/development flow slowing things down. Vista is supposed to be in the realm of 50 million lines of code. Using the same methods Wheeler used to compute linux’s cost and effort, we get Vista being worth a whole hell of a lot more:

Total physical source lines of code:                    50,000,000
Estimated Development Effort in Man-Years:              17,177
Estimated cost (same salaries as linux estimate,        $2.3 billion
  $56,286/year, overhead=2.4)

To me these numbers look just as crazy as the ones in the Linux estimate, but MS being the behemoth it is, I’m not going to try and make a case either way. Just keep in mind that MS would have had to dedicate almost 3,000 employees to working on Vista full-time in order to get 17,177 years of development done in 6.

The important thing here is that by Wheeler’s logic, Vista is actually worth more than linux. By a lot.

Linux fanatics are raving idiots

So all you Linux zealots, I salute you for being so fiercely loyal to your favorite OS, but coming up with data like this (or simply believing in and quoting it) just makes linux users appear a ravenous pack of fools. Make your arguments, push your OS, show the masses how awesome Linux can be. But make sound arguments next time.

digg this!

Typo is my blogging software. Written in Ruby on Rails, it seemed like an ideal choice for me since I’m a big fan of the RoR movement. But like so many other open source applications, Typo has got some major problems. I’m not going to say another open source blog would have been better (though I suspect this is true from other pages I’ve found on the net), but Typo has been a major pain in the ass to upgrade.

For anybody who has to deal with this issue, I figure I’ll give a nice account here.

First, the upgrade tool is broken. If you have an old version of typo that has migrations numbered 1 through 9 instead of 001 through 009, you get conflicts during the attempt at migrating to the newest DB format. You must first delete the old migrations, then run the installer:

rm /home/user/blog_directory/db/migrations/*
typo install /home/user/blog_directory

Now you will (hopefully) get to the tests. These will probably fail if, like me, your config/database.yml file is old and doesn’t use sqlite. Or hell, if it does use sqlite but your host doesn’t support that. Anyway, so far as I’m concerned the tests should be unnecessary by the time the Typo team releases a version of Typo to the public.

Next, if you have a version of typo that uses the components directory (back before plugins were available in Rails, I’m guessing), the upgrade tool does not remove it. This is a big deal, because some of the components that are auto-loaded conflict with the plugins, causing all sorts of stupid errors. That directory has to be nuked:

rm -rf /home/username/blog_directory/components

This solves a lot of issues. I mean, a lot. If you’re getting errors about the “controller” method not being found for the CategorySidebar object, this is likely due to the components directory.

Another little quirk is that when Typo installs, it replaces the old vendor/rails directory with the newest Rails code. But it does not remove the old code! This is potentially problematic, as I ended up with a few dozen files in my vendor/rails tree that weren’t necessary, and may have caused some of my conflicts (I never was able to fully test this and now that I have things working, I’m just not interested). Very lame indeed. To fix this, kill your rails dir and re-checkout version 1.2.3:

rm -rf /home/username/blog_directory/vendor/rails
rake rails:freeze:edge TAG=rel_1-2-3

My final gripe was the lack of even a mention that older themes may not work. I had built a custom typo theme which used some custom views. But of course I didn’t know it was the theme until I spent a little time digging through the logs to figure out why things were still broken. Turned out my theme, based on the old Azure theme and some of the old view logic for displaying articles, was trying to hit code that no longer existed. Yes, my theme was using an old view and the old layout, both of which were hitting no-longer-existing code. But better API coding for backward compatibility would have made sense, since they did give you the option to use a theme to override views and layouts. Or at the very least, a warning would have been real nice. “Danger, danger, you aren’t using a built-in theme! Take the following precautions, blah blah blah, Jesus loves you.”

How do you fix the theme issue, though, if you can’t even log in to the blog to change it? Well, like all good programmers who are obsessively in love with databases, the typo team decided to store the config data in the database. And like all bad open-source programmers, they stored that data in an amazingly stupid way. I like yaml, don’t get me wrong - it’s amazingly superior to that XML crap everybody wants to believe is useful. But in a database, storing data in yaml format seems just silly.

<rant>

Sorry. Anyway, how to fix this - the database has a table called “blogs” that has a single record for my blog. This record stores the base url and a bunch of yaml for the site config. You edit the field “settings” in the blogs table, and change just the part that says “theme: blah” to “theme: azure”. If you don’t have access to a simple tool like phpmyadmin, then you’ll likely have to retrieve the value from your mysql prompt, edit it in the text editor of your choice, and then reset the whole thing, making sure to use newlines properly so as not to screw up the yaml format…. Then you are up and running and can worry about fixing the theme at your leisure.

Now, to be fair, I think I could have logged in to the admin area without fixing my theme, and then fixed it there. But with all the problems I was having, I thought it best to set the theme in the DB to see if that helped get the whole app up and running. Obviously it wasn’t the theme that was killing my admin abilities (and I can’t even remember anymore what it was). But once I hit that horrible config storage, my stupidity felt ever so much smarter compared to the person who designed typo’s DB.

Typo is pretty sweet when you don’t have to delve under the hood. But “little” things like that can make or break software, and I hope to <deity of your choice> that the next upgrade is a whole lot smoother.

UPDATE UPDATE HOORAY

One more awesome annoyance. It seems all my old blog articles are tagged as being formatted with “Markdown”. When I created them, I formatted them with “Textile”. If you’re not up on these two awesome formatting tools, take a look at a simple example (the first is how Textile appears when run through the Markdown formatter):

• This “website”:http://www.nerdbucket.com is really sweet, dude!
• This website is really sweet, dude!

I’ve been using Markdown lately as I kind of prefer it now. But my old articles are in Textile format. I don’t know why upgrading my fracking blog loses the chosen format, but boy is it fun going through old articles and fixing them!!

Digg this!

I’ve just stumbled upon an amazingly misinformed benchmark about Flex, from an actual Adobe employee, Matt Potter.

This guy benchmarks JSON, AMFPHP, and XML as ways to transmit data between PHP and a Flex app. His findings show that XML is generally faster than either JSON or AMFPHP. This “discovery” could revolutionize the way we send and receive data on the net! Who’d have thought that XML is so efficient? Truly amazing results!

But if we choose to drop back down to Earth from the blissful land of Ignoramia, we may find that even Adobe devs can make horrible mistakes.

So why is this year-old article worth dissecting? Simple - it comes up FIRST when you search google for “json flex”, which makes it a great tool of misinformation for people looking for ways to incorporate the awesomeness of JSON into flex! Note that if it were a random article that was at least moderately hard to find, I probably wouldn’t care too much.

So Matt Potter compares XML, AMFPHP, and JSON. His first and most amazing mistake is that he’s using raw XML, but converting data structures in PHP into JSON and AMFPHP. XML is expensive to create as well as to read, so skipping that step completely invalidates his article in my opinion. But worse still, he tests against a local server. The network overhead of XML is going to be significantly worse than JSON in most cases (no idea about AMFPHP as I’ve never used it), so ignoring the 2-3x bigger data really doesn’t do much for providing a valid test.

One of the comments also mentions that there’s a PHP extension for JSON that’s better than what Matt used, and Matt’s response: “I used the Zend Framework instead of the json php extension because I really think that the Zend Framework is the easiest to setup and use, and I have other examples of using the ZF that I’m going to publish”. So instead of looking for the best tool for the job, he went with the easiest tool. But for XML testing he went with the hardest but most efficient “tool”: manual creation of XML with no conversion from objects, no use of XML creation tools, nothing.

I dislike ignorance when one tries to present facts, but this article actually makes me suspicious that his intention was to “prove” XML was the best technology of the three, and was willing to manipulate data in any way necessary to provide evidence. It’s pretty despicable to have a position of influence (adobe employee) and abuse it to prove a totally BS point.

It should be noted that some of the comments, particularly Blaine McDonnell’s, ripped Matt apart better than I can. But when ignorance and/or deception rear their ugly head, it never hurts to point them out one last time.

No, I don’t mean the programming is complete. I mean that I’m pretty much done working on it and it’ll live in its current state indefinitely. It’s fully playable of course, but it’s missing two or three features I would consider core, and has a bunch of stuff I wish weren’t there…. Unfortunately, however, I am finding that I just don’t have the drive to keep working on the game, as it is no longer anything like what I had planned to build.

I have other things I want to build, and this game has been in development for over two years now. If you count the PHP and Perl versions I had to scrap early on, a total of probably 750 hours have gone into it, and I just don’t have the free time to dump that much into a single game when I have so many other ideas I want to play with. Had it been a better game, I certainly would have kept working on it, but I just didn’t keep it focused on the main aspect of the game properly. For more info, read below as I dissect what I think are the biggest problems with BC. This is actually more for myself than anybody else, as I am hoping not to make the same mistakes in my next games.

What went wrong?

Poor Focus

Are you playing to build up an army of gladiators, or to build up the wealth and power of yourself, the manager? The answer is unfortunately both, and very strongly both.

My goal was a fantasy-sports-style game with gladiators. The gladiators themselves were expendable units. You could train them, equip them, whatever. But at the end of the day, you were merely supposed to be building a team to further yourself as a manager.

I don’t know how all fantasy sports games work, but the one I did play had very basic players that you controlled in a football (American) league. There were a few stats on each player, as far as passing, punting, blocking, etc. But for the most part it was about building a team that worked well together, and reading the game commentary each week to see how well you did.

Well, I got so wrapped up in the coolness of my RPG stats for gladiators that I made it cumbersome to manage them. Each gladiator needed several tabs to view all their details. The overview, which showed all the gladiators “at a glance” was unfortunately lacking enough information to really make meaningful choices. Add in all the ways weapons could modify a gladiator, and how different stats worked with equipment, and of course the ranks thrown in as a typical RPG leveling system, and you’ve got a lot of information to deal with.

In a game where you are the gladiator, this works out just fine, and in fact you’d probably want even more focus on stats and things. But when you’re just the manager, you find that managing your small team of 5 gladiators is a big pain.

Additionally, the focus being so split between gladiators and managers meant that building up your manager was never really emphasized. You had one stat, fame. It meant very little after about a month or two of play. You had money and equipment, but again, those meant nothing after a short amount of play.

No Team Spirit

This is sort of an extension of my lack of focus. In a fantasy sports football game, your team is a single unit. An injury in your quarterback means your whole team suffers, so you need to have a backup. Too much focus on speed and not enough on blocking, and your team is crap even though they have the best runners in the league.

In Bloodsport Colosseum, however, your “team” was a group that had no interaction except that they sometimes fought each other. That is totally not how a team in a fantasy sports game should act. It was essentially like managing a bunch of boxers, except that you couldn’t even properly choose matches because I didn’t want the players to be able to abuse the game (the computer chose matches each night).

If I’d done this as I meant to, your team would consist of at least 10 gladiators, and you’d need different specializations for your team to win. Or maybe not 10 gladiators, maybe fewer would be fine, but they would need to work together somehow.

Priorities

Tournaments should have been the first kind of match to exist. They were always on the list of things to do, but never made it to the top. Yet I think they make more sense than the green/blue arenas. Apocalypse matches were okay, but just too chaotic since I had no teaming mechanic.

Achievements should have been very high priority. You are managing a team of gladiators, and yet I never built in medals, trophies, or anything like that. While the effects on the game may have been minimal or none at all, the desire to be the best manager would have meant something! Comparing trophy cases, bragging about the elite “1000th kill” award, etc. Yes, eventually long-time players would grow bored of having every trophy available, but this would have at least made the manager a more tangible piece to the game.

Spending most of my time on gladiator stats and weapons was just a mistake. Complex gladiators aren’t necessarily a bad thing, but they shouldn’t be a burden. In a fantasy sports game, you might do basic training on your players, and you will likely choose some high-level organizational things (positions on the field and such), but you shouldn’t have to make several choices every single day on every gladiator in order to keep them working well. Having simpler stats, training, and equipment would have left a lot more time to do other things that should have been higher priority. Such as tournaments and achievements….

Manager stats should have been a priority, too. I had a plan to have managers gain specializations that helped out gladiators, with their own stats for attack, defense, money management, healing, whatever. After a certain amount of XP, you spend it to gain a new skill or something. This may not have worked well - it may have ended up being really confusing, in fact. But at least it was the right direction - focusing on the manager.

Fight logs sucked. They were just a bunch of “A hits B for X damage” kinds of messages. Making a robust combat engine should have been done before even going into closed beta testing. The fight engine was too simple, and it was one thing that could be complex as hell without confusing the player, since it was totally hands-off. Players should have been excited to see the fight log, to read a mini-story that was detailed and interesting, describing feints, parries, dismemberment (another dead idea), etc. Instead, it was always something I felt could wait until later.

Ideas For Next Time

I don’t know that there will be a new BC ever. But if there is, I have some ideas for it.

1. Gladiators will be much simpler. No levels (ranks), or if there are levels, they’ll represent experience without giving additional bonuses to stats and hit points. Gladiators will have different stats that represent more tangible abilities, like the derived stats do today. And your choice will be simpler - each stat will be set and never change. The choices will likely be word-based, such as “very weak”, “weak”, “average”, “strong”, and “very strong”. So you may have a gladiator who is “very strong” at Offense, “weak” at Defense, “average” at Speed, and “weak” at Toughness (hit points).
2. Recruiting stations will still exist in some form, but they won’t have such an effect on the gladiators. In all likelihood they’d have options that gave, at most, -1 or +1 boosts to specific stats, so that instead of all your stats averaging out to 3 (”average”), you may have them averaging 2.5 - 3.5.
3. Your gladiators will work as a team by default. Maybe I’ll still allow one-on-one challenges, but I’m not sure I like how challenges ended up working in BC. I definitely didn’t like the arena choices, as I couldn’t explain them well to people, they required you to choose an arena for every gladiator, and they made the system have to be out of sync in order to have pre-scheduled battles. It was just confusing - a simpler approach of setting your team in a league or something would be more interesting as well as more user-friendly, I think.
4. Training will be simple or nonexistent. Skills will be simple or nonexistent. If they’re included, skills will surely be complex behind the scenes, such as the combat training value is today, but the player won’t see it or have to deal with it. He’ll just see that a gladiator has a certain amount of experience with bladed weapons. When training happens, it’ll be a long-term thing. You set John Doe to train blades, and he’ll train every day until you change this preference. He’ll move up through 3 or 4 ranks of training, Basic, Advanced, and Expert or something. These will modify him in some way that will make fight logs more interesting, such as being able to parry or riposte where he previously couldn’t. Battle experience will affect attack chance and perhaps damage, while training will affect “moves” available. And it’ll all be something the player notices only passively, so it’s interesting but not cumbersome.
5. Gladiators will not have scarring. They’ll have critical injuries which require time out in order to heal (which of course should affect the team as a whole). They may lose limbs. They may die. The player won’t have much say in this at all, other than perhaps choosing an overall team strategy that’s risky. Gladiators missing limbs will almost certainly need to be retired, but mid-season it may be better to leave a one-armed gladiator in, if his experience and training are really good.
6. Equipment will be simple again. Simpler even than what I had when I first showed BC to the public. There will be a few choices for each group of weapons, and they’ll be very simple choices. Maybe 3 weapons per group, with maybe 3 levels of quality. And weapon damage would be the main stat, with a small modifier to speed. Some weapons would be better for parrying, perhaps, and blunt weapons would deal different damage than bladed (crushing limbs versus open wounds), but the player wouldn’t care about much other than damage and “oh, the sword will allow a parry more often, great.”
7. As I just alluded, there would be a little more in-depth combat damage. This would be added complexity to the backend, but not something that the players would ever have to pay attention to if they didn’t want to. The most important thing about adding complexity to this kind of game is to make sure the user doesn’t have extra micromanagement just for the sake of adding more to the game. Anyhow, the combat engine would be more sophisticated as I’ve stated, with things like parries, ripostes, sudden berserker-like rages, etc. But also, damage will be totally different. Hit points are great for a traditional RPG, especially one where the character is expected to survive many brutal battles. But in a game where the warriors are expendable, a much more interesting combat system should be looked into. I wouldn’t build a truly realistic system, otherwise most gladiators would die most of the time, but I would make it semi-realistic. Damage would be to specific body parts, death would usually be from blood loss or brain damage, etc. Hit points would exist perhaps on individual body parts to measure how useful they are, but they wouldn’t determine life left. For instance, if you destroy my arm, I can’t use it in battle anymore, but further hits to that arm don’t really do much to me - it’s probably already bleeding as much as it can.
8. As I stated above, the manager would be the focus. Players would be in the role of a manager, and would have more choices about their management than about the gladiators. Perhaps they’ll be able to gain experience, but no matter what mechanism I choose to deal with manager persistence, there would be ways to carry over something no matter how many seasons a manager played. A long-term player should be able to show trophies, medals, and other awards. There should be all kinds of random “top player” lists, showing obvious achievements like kills, wins, KOs, etc. Special awards would have to exist that players wouldn’t even know about until they won one, such as an award for crippling a large number of opponents. Maybe allow managers a long-term inventory of manager-specific “artifacts”, which would give minor boosts to his gladiators in addition to his own experience. Overall a long-time player shouldn’t be able to easily crush every n00b he encounters (although separate leagues for the newest players could alleviate this some), but he should have a small advantage for sure.