The move to typo 4.0

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>

PEOPLE, LISTEN UP, if you’re going to store config that’s totally and utterly NOT relational, do not use a relational database. It’s simple. Store the config file as a yaml file. If you are worried about the blog being able to write to this file, fine, store your data in the DB, but at least store it in a relational sort of way. Use a field for each config directive if they’re not likely to change a lot, or use a table that acts like a hash (one field for blogid, one for settingname, one for setting_value). But do something that is easy to deal with via SQL. Show me the SQL to set my theme from ‘nerdbucket’ to ‘azure’ please. When you can’t use your database in a simple, straightforward way, you’ve fracking messed up. Yes, there are exceptions to every rule, but this blog software is not one of them. It would not have been hard to store the data in a neutral format that would make editing specific settings easy.

</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!

June 11, 2007June 27, 2007

How not to benchmark software

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.

June 4, 2007June 27, 2007

Bloodsport Colosseum Finished…

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.

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).
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.
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.
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.
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.
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.”
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.
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.