Archive for March, 2007

Difficult Names = Bad?

Tuesday, March 27th, 2007

Lets try a little experiment. (Try to) read this.

Sykhronics Entertainment

Anyone that’s followed my work probably won’t be miffed by that mean looking first word. But if you stuck around, you stuck around for my work, not my clever name. You probably have your own pronunciation of it too. I’ve certainly heard some interesting ones from telemarketers that whois’d my domains for a phone number.

Lets see if we are thinking the same thing. Here’s me saying it.

How did we do? Drop me a comment.

That crazy invented word “Sykhronics” is something I came up with some 9 years ago, in 1998 I believe. At the time, Gamma Flare Games just didn’t seem cool anymore. It’s been a branding for personal productions, and when I started my own company, it became my company name. Having worked under the branding for so many years, I never really thought about it twice. I simply saw that registering it as a business was the next logical step.

Oh, and it has a silent “H”. Whodathunk.

To me, the name sounds (sounded?) cool. Kinda like a bastardization of Psi or psyche and electronics. Brain or mind technology, or something. Growing up a nerd, you tend not to be the cool kid, so you invent your own cool.

But you see, I was generally oblivious to the idea that difficult names are hard to say. You see, I have another difficult name to deal with. My own last name. Kasprzak. Spell check likes to tell me that I spelled Kasparov wrong. Here’s how my family says it.

I’m sure the Polish have their own pronunciation, but this is the Canadianese bastardization my family and I use.

There are pluses to obscure names. If it’s not too similar to anything people have heard before, then it becomes memorable. But that’s the trick. Lets take a fictional company, Muttant Games. Without a dog for a logo, you might miss the “Mutt” aspect. If you have any sort of comic or cartoon background, you probably see it as Mutant Games. But in fact, you were being clever, so your logo is a deformed dog thing. This is a pretty tame case.

But lets hop over a more obscure. Xanyatkiera Industries. WTF!? It’s nearly as bad as one of those ridiculously bad sci-fi names with all the apostrophes (Nak’tyla’i of Zya’ka’dal’ee). If anything, I’m just trying to encourage people stay away from the obscure.

That goes for character names too, not just companies. There’s something to be said for the clarity of phonetically consistent names. I don’t know about most people, but if I come across an Apostrophe Name, I tend to glare away and make something up that matches the apostrophe pattern. That’s bad for storytelling, as it’s a strike against your immersion. My apologies to the lizard people and aliens that do have them in their names, but you can find an adaptation that’ll please everyone if you try. Spaces, extra e’s, whatever.

Back to companies, picking a name that’s available in .com form is ideal, since it’ll only cost you $8 to claim your professionalism. Obviously the more obscure you get, the better the chances it’s available. There’s a reason is taken, but isn’t (*yoink*).

Names are important. Just a few a things things to consider, before you end up beginning every business meeting with the pronunciation game.

Trackers and Sequencers rant

Sunday, March 25th, 2007

Ranting… I’m sorry. :)

I suppose I’ve been “writing” music with trackers for about 13 years (Scream, Impulse, Modplug, Buzz, Renoise). Alas, my results have been less than satisfactory. I want to take this moment to apologize to everyone I ever recommended trackers to.


Sometime last month I set out to find a better music app. I’d already entered the world of VST’s thanks to Renoise, having put down a big $600 for Colossus. I’ve spent a lot of time in Adobe Audition (Cool Edit) over the years too, so that’s where I started. I wanted something akin to it’s multi-track view, that I could sequence midi in. I decided to give all the big name non proprietary apps a go (i.e. Pro Tools). FL Studio, Acid Pro, Sonar, and Live.

FL Studio, I love the synth VST’s it comes with. But I honestly got lost in the interface, trying to figure out how I was supposed to track stuff.

Sony’s Acid Pro was the easiest to get up to speed in. A good app. It generally did everything I was looking for exactly how I wanted it, scroll wheel and all. It can create “ghost clips” too (i.e. update the original, and all clones get the changes). However, I was having troubles using multiple Colossus instances.

For one reason or another, I glazed over and generally ignored Sonar. It reminded me too much of Cubase. Nice job with an impartial assessment there Mike. :P

I ended up going with Ableton Live. It’s certainly a qwirky program, doing just about everything in it’s own way (click+up/down to zoom, click+left/right to pan). It actually took a lot of effort to really understand how to work in the app. But it does so many things right for how I want to work. Cross platform, since I have this mindset that I want the option to go Mac one day. And the key point as I saw it. You can bake tracks! OMG! If you’ve used a heavy hard drive streaming sound sample library like Colossus (Kompakt) or Giga Studio, you’ll note that one of your bottlenecks is the number of instruments you can play at one time, before your playback begins to stutter. I hit that at about 3 separate instruments (with numerous layers each). Not a problem with Live. Right click on a track you’re not working on this moment, hit “freeze track”, and within several seconds it’s rendered that track to disk. Then when you want to edit it again, right click and unfreeze it. Mmmmm.

That feature alone sold me.

But as I started digging through the interface and tutorials more, I really think I made the right decision. The interface has 2 views. A clip editing/mixer view, and a master song arrangement view. I wont delve in to all the details, but you can actually edit clips in both views. The clip/mixer view is actually designed for more of a “program the song and perform it live by queuing rows” type interface monster, but I found another use for it. Doodles. I don’t know how everybody else works, but sometimes as I’m toying on my midi keyboard to come up with a part or layer, I come up with something interesting, but it doesn’t work for this song. In the past, I had no way to record these random brainstorms. With Live, I solo the track, pound an empty clip’s record button, and record my music doodle. Then I can easily tweak my notes, if I hit something too early or too soft, and it doesn’t hurt my song at all. I can then export the mini composition to a .mid file, to use elsewhere.

So in conclusion, I’d like again apologize to anyone I ever recommended trackers to.

Deskonomics: Shape

Wednesday, March 21st, 2007

Here’s a fun point. Almost everyone works at a desk, but nobody talks about desks. Chairs come up sometimes, especially in discussions about the Aeron chair versus a well made leather, or general sitting ergonomics.

This is an incredibly broad topic that could easily span dozens of blog posts in it’s complexity. Game developers and other media professionals have many needs for their working surface. And depending on how many hats you wear as a developer, you’ve got to fit several monitors, speakers (stereo or surround), input devices (keyboards, mice, tablets, midi interfaces), scanners, printers, and other office friendly objects (fans, phones, paper and supplies) on it. So lets start with a simple yet significant point. Desk shape.


Desks bought from retail come in 1 of 3 shapes. Rectangular, L shaped, or U shaped.

An advantage of a rectangular desk is you can combine it with any number of rectangular desks or tables to create any desk arrangement you like. You’ll have to be careful when it comes to height and depth, as you’ll likely want them to be them to match somewhat.

The L shape desk is a nice shape, since you get stuff in front, and more stuff to the side. Or the side gives you some additional workspace, if there isn’t any in front.

But as far as these shapes go, the U is clearly the winner. The bigger the desk, the more crap you can fit on it. You get all the space fitting advantages of the L, with an extra rectangle for more crap, or as a work surface.

Game development is a very collaborative process. Now, I don’t care if you’re a lone wolf indie developer that lives by yourself. You’re going to eventually have somebody over, and it’ll be beneficial to have them sit next to you.

Here’s the real motivation of this post. You can fit somebody beside you in any reasonable rectangular and L shaped arrangement. However, U shaped desks, there’s a problem. If your computer monitors are in the middle of the U, then people can’t sit beside you. Their either going to have to sit or stand behind you, or far off to the side.


From experience, this isn’t good. People complain about not being able to read the screens, or the colors look different (off axis LCD viewing), or any number of complaints. Or if nobody is complaining, then you’re hurting the collaborative potential by not sitting them beside you.

You can solve this problem relatively easily by putting your monitors on a side of the U.


However, desks are commonly designed with the keyboard shelf fitted to the middle spot, or on an angle in between. On the plus side, some drawers can be converted to keyboard shelves. If that’s not an option, with a little bit of craftsmanship, you can add one. The parts can be picked up at most hardware stores.

Few developers will make the opportunity to have or build a custom desk, but the U problem mention above is something to take in to consideration. A fat U shape could work, but it’d need to be really fat to fit 2 quality chairs. Custom desks are a topic all on their own, so I’ll save that for another day.

And that about covers desk shape.

Tips for Input Recorders

Saturday, March 17th, 2007

This is part of a forum post I made. Classic Mike, going completely off topic and force feeding all the random advice I had saved up.

– – – –

Be sure your input update is written/recorded immediately before the game processes it. In other words, at the end your control interpretation code/handler. That way it can “in theory” reproduce a crash, instead of coming up a frame or two short. So if it doesn’t crash, then your crash is likely related to an uninitialized variable. So you forgot to set it in a function, initialize it to zero in the constructor, or set/handle a pointer. Hardware/Driver/Compiler problems are a possibility, but there’s an incredibly good chance it isn’t. Be wary of GCC the 3.0.x series though (anything newer is much more reliable, 3.1.x+, 4.x, …).

Compressed input recording is good for attract mode and in game replays, but not so much crash reproduction (especially if you’re waiting on changes before you write).

Prefer fixed framerates for internal clocking. This’ll make reproduction/playback of non rendering bugs/crashes easier.

Recording the initial random number seed is helpful too. And if you don’t reseed, you don’t need to record reseedings. It’s so very easy to do this too, it can essentially be your file header of an input recording file. Read and populate the seed first, then playback all the following input commands. Technically, you shouldn’t ever need to reseed, unless you’re making a multiplayer game.

Testing Methods

Saturday, March 17th, 2007

This is from a forum post I made in response to a question on testing methods. A classic Mike random advice assault. This branched off to a series of thoughts on built in game recorders.

– – – –

Free testing methods:

Peer testing has worked well for me, as developers tend to have bizarre PC configurations (multiple monitors, multiple gamepads, etc). There’s also a level of critique a developer can give that goes above and beyond, but you need to be clear and capable of asking for the harshest of critiques.

One I’m looking forward to giving a go, bringing several friends over for a testing weekend. It’s maybe not totally free, as you should feed ‘em. You can’t go wrong with pizza.

Another I’ve considered but haven’t tried yet is school testing. In theory, this should be a really great user test environment, but perhaps not the best bug test environment. Your choice of High School vs. Grade School should reflect your desired ESRB rating (E vs T). Visit a local school and speak to the principal about arranging such an event. Borrowing a room, any TV’s or computers, etc. Be prepared to supply equipment though. You may need signed permission forms too, especially if you want to videotape aspects. Recording features, weather integrated in to the game, or via a VCR are a great help for tracking down bugs. And finally, be prepared to be asked back to talk about game development in a programming class. :)

And of course, releasing the product after some free testing on your website can work too, and wait for bugs to come in by e-mail/forum. You should do your best to be sure she runs on a number of configurations first. Then approach your distribution channels, and media coverage after a few weeks of user feedback.

Paid testing:

Testing has to be the worst job in game development. Playing the same game over and over again … awful I say.

Having an in house tester has worked nicely at places I’ve worked, but it’s no replacement for a harsh round of QA at Beta. The only issue has been down time if they’re full time. But hey, as a small developer, you can always find some task for them to do. You can always think of them as an assistant. Converting files, managing forums, doing tedious tasks like building maps for casual/puzzle games.

And as for outsourced testing, I think it’s essential for any retail or console downloadable game. Some publishers and portals have testing departments. The testing company will send you a bug list, or update a bug database for you. Some of the better ones record their testing sessions, and send you screen shots or video of the bugs they’re trying to describe. This can be a pricey service though, but as I said, essential in some circumstances

Tips for Game Archive Formats

Friday, March 16th, 2007

From a forum post, a set of bullet point advice on creating a custom archive format.

– – – –

– For terms: Archives are a directory/dictionary/list of filenames with offsets to chunks, and many data chunks (files). Compression comes later.
– Directories and subdirectories are just longer filenames. Unlimited file name length means unlimited directories.
– Padding the start of data chunks to 4 byte boundaries has performance advantages on many platforms when in RAM.
– For random access, compress chunks individually. Compressing everything at once tends to save more space, but you trade off random access.
– If there’s room in RAM, cache the archive. At the very least, caching the directory/dictionary can improve load times by not having to read it every time you request a file.
– If there’s more room in RAM, compress the archive as a whole, and cache the uncompressed copy after loading. But keep in mind, you need slightly more free memory than the sum of the uncompressed size and the compressed size.
– If running off a CD/DVD, seek time sucks. If you can’t cache everything important or commonly used in RAM, replicating your archive on different parts of the disk can improve seek time. A simple check of what sector the last file request was on disk, and a little math to pick the closest to where the laser sits.
– Seek time on memory cards/flash memory is significantly better than CDs/DVDs, but random access is still slower than continuous access.
– Prefer (if possible) ordering data on disk/archive in the same order it’s requested. Though that’s a bigger impact with CDs/DVDs, it’s something that can be considered when talking about your own archiving.
– Storing all files in the same directory in the same general part of the archive can achieve the previous point, so long as that data is of “Level 1″ or “Level 2″ type scope.
– Accessing distinctly common data first, then level specific data can save seek time if the common data is far away on disc.
– Storing or interweaving streamed data together can save seek time (music, video, static geometry).