20 January, 2013

Of games and scripting, and scripting games

Life's not always a game, but it can seem like it

It's been a pretty long time since I've contributed to either of my blogs recently. Not that I've been doing a lot, though I have been contributing to the coffers of Steam and Indie game creators, mainly through the Humble Bundles.

A little humility goes a long way

Humble bundles are collections of (usually) games typically from Indie developers, and the ones I look at are at a knock-down price. In essence, you specify the price, and specify how you want the price divided up amongst various categories. Independent game developers get much-needed profile as well as a little extra cash in their pockets, any charities get a little bonus and the group organising this also gains a slice. And it's all decided by you and me, the prospective purchaser.

You certainly won't find Call of Duty, Halo 4 or any other big AAA titles in these collections, as those are normally funded by organisations the size of Valve, EA and the likes. No, these are little games, often coded by one person, or perhaps more, but usually no more than ten people.

These humble bundles work best when we're not cheap retards that pay one cent and expect seven good quality games. One current way to combat this is to provide basic games for any amount less than the average. Additional games are provided if the prospective purchaser pays more than the average. If we're prepared to put a halfway decent amount of money towards the games, then developers are more inclined to look at this as a viable way of increasing visibility.

The Humble Bundles provide binaries for Windows, Mac OS X and Linux. I think that's fantastic, but I noticed something about contributed amounts for various platforms. Windows users provide more than 60% of the purchases, yet they're the cheapest of contributors. On the other hand, Linux buyers provide the greatest amount for contributions even considering their lowest profile. I wonder why that is?

As a result of my various contributions to their respective coffers, I have stellar little gems such as Gish, Toki Tori, Cave Story +, and many others.

I do run the risk though, of running into an awful lot of games that I'll probably buy, play once or twice, and then hardly ever play again. Minecraft seems to be a very rare exception to this.

One small niggle I seem to have, Steam's copy of Doom3.exe doesn't want to work properly on my computer, and nobody actually knows why. I've downloaded the Doom3.exe from ID, and that seems to work fine. In addition, so does the Linux binary. So it seems that the data files are fine, at least. It's just the binaries.

However, in more testing, it seems it might actually be the Steam interface that isn't running something the steamed-Doom executable expects. Once I was running the beta Steam client, it now seems to work properly.

Except for Defense Of The Ancients 2, which has issues of its own that I have yet to understand.

Houston, we have lift-off

On the topic of Minecraft, I cobbled together a script (called minecrafty) to start off a selection of Minecraft launchers. The launcher handles loading modifications to Minecraft, and my script handles other items such as screen brightness, choosing the right launcher and defining the amount of memory devoted to java.

Since then, I've added other functions. I added in the ability to run a specific server, or download versions of Minecraft, and most recently, to download various launchers. Currently it only works under bash, as that has a far better ability to chain commands together. Heck, bash even has functions, and has done from day one. I don't know if CMD.EXE even has functions, though it has callable subroutines, but I do know it was a pig to write for when I last wrote for it. So I write minecrafty in the bash scripting language.

I can't think of much more to add to minecrafty, as it has everything I need it to have. And frankly, that's often what home coding is all about—scratching an itch. I needed to brighten up the screen before launching Minecraft, and reduce the brightness back to normal afterwards, which is how this all started. In doing this, I found out a little more than I really wanted about how to change brightness on individual monitors (and refresh rates) of my two-monitor system. I was also surprised about just how much detail I needed to know about. For example, someone was having total problems starting my script on their system, purely because they hadn't put things in the same place that I had done on my system. That provided me with the impetus to add in a function to download (and install) a launcher. At this stage, the script supports five separate launchers, with no real plans to support any others—as it is, I only use the one launcher anyhow.

No comments: