GameFAQs is running a contest to name the best game ever and some of our SEGA favorites are included. The polls open on April 3rd and run until a new winner has been crowned. Does this sound familiar? It might, GameFAQs originally ran a best game contest five years ago with a winning entry of Final Fantasy VII. Not that I’m anti Final Fantasy, but I think we can all agree that Streets of Rage 2 or the original Sonic the Hedgehog Series (1, 2, & 3) on Genesis should hold the spot. I’m partial to Streets or Sonic 2 myself, but hey, you vote for yours and I’ll vote for mine .

To prep for the polling event, GameFAQs has set up a contest to test your powers of prediction. The contest actually started on March 10th and will end just before the polls open on April 2nd. This gives a preview of the game list and also offers a nice checklist for some of the, well, best games ever. Take a look and see how many you’ve actually played, and if your really good, finished. I’m looking at about 80% completion and a lot of great memories.

Of the games listed, you can find SEGA games listed in the following brackets:

1989-1991
Sonic the Hedgehog

1992-1994
Streets of Rage II
Sonic the Hedgehog 2
Sonic the Hedgehog 3

We’ll check back on April 3rd to watch how it all plays out, in the meantime, you’ve got a great list of games to play before you decide what the Best Game really is. Best of luck to everyone!

Submit Your Winners for the Contest

Ever wonder what it’s like to present the news? They may seem like they never flub a line or miss a beat, but as anyone who’s seen (or been on) live TV can attest, bloopers can and do happen. The MADWORLD TV crew is no different, and we’ve put together a reel of the best bloopers from the taping of the MADWORLD TV trailers.

The blooper reel is up on GameTrailers now!

If you haven’t seen the previous MADWORLD TV videos, you’re in for a treat. These videos have been getting a lot of attention around the net — over 100,000 views and tons of comments. From GameTrailers:

MADWORLD TV 1

MADWORLD TV 2

MADWORLD TV 3

MADWORLD TV 4

Like a lot of people, I’m crazy about my iPhone. So many people at SEGA have them, that when we all get invited to a meeting, there’s a flurry of calendar alert sounds from everyone’s phones. I’ve had my phone since the first day they were sold (yes, I was one of those people waiting in line outside the mall. Yes, it was worth it.) and I’ve eagerly followed the evolution of both the hardware and the software. So I was really excited to hear what would be announced at Apple’s iPhone OS 3.0 event this past Tuesday.

There are over 100 new features, and although I’m happy to talk about them all, you’re probably wondering what this has to do with SEGA. Apple has made some revisions in the software development kit for applications, and opened up some new functions for applications. These changes bring some incredible opportunities for both application makers and application users.

Perhaps the biggest change to the applications is that makers can now sell content from within the app. This is great for magazine, newspaper, and e-book distributors, because now they can make one app and sell subscriptions from within the app to load new content. But it’s also great for game developers like us, because we can sell additional levels, additional weapons, and additional content from within the game. It opens up an entire world of possibilities that weren’t there before.

But you might not be as enthusiastic about this. Some people think it’s just a way for app makers to squeeze more money out of customers — to nickel and dime them to death or to charge them more money for content that should have just been there at the original price. And I can definitely see how unscrupulous app makers could attempt such a thing. I’d like to think that most app makers respect their customers more than that, and that customers would be quick to call out any app maker that excessively and unfairly charged customers.

I think this allows games to be more expandable and longer-lasting. Under the old model, you buy a game like Super Monkey Ball (for example), play it, finish it, and are done with it. You can play it again if you want, but it is what it is, and you’ve already been through it all. A lot of people won’t go back and play a game, so they end up pushing the app to a back page and ignoring it. But under this new model, game makers can keep adding interesting content, potentially making a game new and interesting (and engaging) for months or even years. If you like Super Monkey Ball enough to want more, you can get more in a seamless continuation of the original app. If not, then you don’t have to.

It will also be interesting to see if the pricing schemes for games change to be less money upfront, but more add-ins. Although this may also feel like nickel-and-diming, it may work out better for everyone. Game makers may sell more initial installs because there’s less risk due to the lower pricing. And gamers get to try a game out without throwing down too much money. If they don’t like it, it’s not a huge loss. If they do, they can pay to keep going.

Is this something you’re looking forward to, or something you’re dreading?

If you have some free time and some artistic talent, you could win a rare MADWORLD hoodie from VGChartz! Even if you’ve already entered to win one at Sega Nerds, you can hedge your bets by entering the contest at VGChartz by March 23rd. Here’s how:

Create something MadWorld-related in a black-and-white-and-bloody-red color scheme, using one of two methods:

1. For the more arts-and-crafts oriented, submit a photo of a physical art piece you’ve created, making sure that a sign with the text “VGChartz” and your username is visible in the photo.

2. For you Photoshop wizards out there, submit an image of fake MadWorld merchandise (ie. posters, cereal box, figurines, toys, etc) with the filename “VGC_MadWorld_your username“, replacing your username with your username, obviously.

In both cases, send your entries in .JPG format to contest@vgchartz.com with the subject line “MadWorld Contest” by 5pm PDT on Monday, March 23th. Finalists and winners will be announced later that week.

1. Only VGChartz members are eligible. Sign up for free today!
2. You must be 18 years or older to claim a contest prize.
3. Any cheating or attempt at cheating will result in an immediate lifetime ban from all future contests. Contest entries must be original, not reused from previous activities.
4. VGChartz staff members, including Site Admins, Moderators, GameDB Admins, Contributors, and Poll Admins, are not eligible to win prizes, nor are their relatives.
5. By submitting a contest entry, you grant VGChartz the right to use and modify your entry for promotional purposes.
6. Winners will be notified via a PM to their VGChartz username, so make sure you provide it in your contest entry! Winners will have 30 days to supply their full name and valid mailing address or they will forfeit their prize.
7. The contest is open to entrants from anywhere in the world.

Best of luck to everyone entering!

At the Total War blog, Mark has posted an explanation and some tips for creating Empire: Total War mods. We’ve already seen mods being created, and there’s clearly a demand for more. The mod dev package is coming, but in the meantime, here’s how to work with the modding system, not against it. Using this knowledge, you can avoid breaking things released by CA in the future.

First of all, the ETW data is meant to stay packed. The pack file system and the virtual file system that it builds internally within the game are central to the patching and modding systems, so please don’t ask users to unpack their data in order to run with your mods.

So how should you mod the game? Well, it works like this. Empire loads files of type .pack in the data directory in a certain order determined by the pack’s type. There are three basic types – release, patch and mod. The fifth byte in the pack file header is an numerical id which tells the game what a pack is, boot packs are 0, release packs are 1, patch packs are 2, mod packs are 3. The game then loads release packs first, then patch packs, then mod packs.

At game startup, the file entries in all of these packs are mounted into a virtual file system, and if the game finds an entry in a later pack which has the same name and location as an already existing entry, the new entry replaces the old. This means that a mod pack can replace any file in the vfs and add new ones as well, without asking the person who downloaded the mod to overwrite files on disk and destroy data.
In order to tell the game to use a mod, you do need to feed the game a script command. Currently the easiest way to do that is to create a user script file. The way to do this is to find your preferences.empire_script.txt file (this will be in Application Data on a Windows XP machine), and create a text file next to it called user.empire_script.txt. Inside that file, for each mod create a line which reads “mod my_pack.pack;” (without the quotes, obviously). The user script gets processed on load, and will tell the game to load your mods in that order. The user script can be used for many other things as well, but we’ll leave those for another day.

So basically, a mod is intended to be a single “mod pack” file, and installing a mod is just placing that pack inside the game’s data directory and adding the mod command, and uninstalling it is removing those things.

Now, a note on how to work with the databases. You’ll have noticed that each table in the databases (inside the db folder) is both a folder and a binary file. When the game instantiates the databases, which happens after the virtual file system is built, it scans each directory and parses -all- of the binary files it finds. This means that a mod pack can add a new binary data fragment inside the db/unit_stats_land_table folder which adds several new units, and the game will add them to its land units database. The fragments are processed in the same order as the pack files, and any new database records with the same name as an old record will cause the new to replace the old. This means that you can replace any record within the database without touching the rest of the data or modifying the CA-supplied files on disk.

For example, say the CA packs contain a unit record for ‘french_dragoons’, which is one entry out of hundreds inside the shipped unit_stats_land_table data fragment, which is used to build the unit table that was available at launch. Now say you create a mod pack which places a new data fragment, say called my_mods_unit_stats_land inside db/ unit_stats_land_table, which contains just one data record for ‘french_dragoons’. What will happen is your new record will end up replacing the current record for that unit in the game data, and the rest will stay as it was originally.

So… hopefully you’ll now have a good idea of how the modding system was architected, and how you should build tools to work with it. There’s also another interesting consequence of how the system works, which is that it opens the door for mods built on top of other mods…

One more thing to keep in mind is that we’ve not yet finished testing the mod support fully – that’s part of what’s happening here before the mod dev package gets released. We’re aware that there is currently an upper bound of about 6000 files in a single pack, though it’s very possible to create a mod spanning several packs. But be aware that there is some overhead associated with mounting a pack, and a data directory filled with scores of them will make the game startup time significantly longer.

The other thing I should mention – since you’re going to be experimenting with this – is that the game checks the final database integrity after loading mods. So if you add a pack file which includes a new unit record which doesn’t include a display model or is invalid in some other way, the game will unload that mod pack (though it keeps the rest). This isn’t the main error checking mechanism in the ETW data pipeline, that’s done elsewhere, but as modders you should be aware of it. Unfortunately there currently isn’t any log output on the reasons why the mod failed to load, we’re looking into adding that when the modding dev kit is released.

Armed with this info you’ll at least be able to work with the system as it was intended, without having to wait for the mod dev package. I have to say it’s great seeing you guys making headway so quickly. The pack and database inspection tool was a great start, I think, and really bodes well for the future of the Empire modding scene.

Good luck!