VectorStorm Blog

People look at me funny when I tell them this, but I’ve always had this strange, irrational desire to play a game where I got to pilot a properly huge capital ship.  Something like a Star Destroyer from the Star Wars universe;  something that takes a good three to five minutes to turn around.  And I don’t want to turn the ship by clicking on a UI element that instructs an auto-pilot to turn the ship around, and then perhaps speed up time to make the auto-pilot complete the manoeuvre faster;  no, I want to be able to have direct joystick control to the ship’s thrusters.

I occasionally think about making such a game myself, some day.  But it seems like a lot of effort to go to for an experience that nobody but myself would likely be interested in.  Or rather, anyone who might be interested in such a thing is probably playing Eve Online.

Instead, I’ve been playing around with Independence War a bit, which is a game from way back in 1997, and which was kind of halfway to what had been in my head.  Of course, it isn’t pretty by modern standards (or even by its contemporary standards).  And it’s not accessible at all — it positively requires reading the manual to figure out what’s going on, and the difficulty curve is all over the map (I was stuck on the first combat tutorial level for the better part of a week, for example, because the training opponent kept absolutely steam-rolling me).

I-War is pretty squarely focused on combat, rather than on exploration or.. well.. anything else at all.  but its deep simulation of a large starship, its component systems, and the mechanics of piloting it in a frictionless, zero-gravity environment are intriguing, and I keep wondering whether something more interesting than “…and they fight!” could be done with such a system.

I realise that this probably dates me horribly, but I’ve always felt that games such as Elite were made a lot stronger and more compelling by forcing the player to learn non-combat skills, such as learning to dock their spacecraft manually, learning to trade goods on their economic markets, figuring out how to navigate from place to place, and so on.  These extra things to do just made the world larger and richer than the exclusively-combat-focused games which followed.

I mentioned a few weeks back that I’ve switched to using Vim as my main editor, and couldn’t be happier.  A lot of that was due to my personal dislike for features which are becoming increasingly common and difficult to disable in popular IDEs, and which I can completely disable within Vim.  But to be honest, most third-party editors would work just as well;  Vim just works for me.  Others can (and do!) prefer Notepad+, Emacs, TextEdit, SublimeEdit, and others.  The key point I wanted to make to other programmers is that it’s worth experimenting with text editors — there’s no need to lock yourself to the one that came with your IDE!

Anyhow.  At a similar time to when I started using vim, I started experimenting with using git, rather than subversion, for source control.  This wasn’t for any special reason, just that I’d been learning a little git (since it’s very popular amongst vim users), and wanted to make a lightweight repository for tracking changes to my Vim preferences.  And then for fun, I imported the MMORPG Tycoon 2 history into git

For me, the best feature of git, compared against subversion, is the ease with which it handles branching and merging, which were always at least mildly painful under subversion.  With git, though, it’s so easy to maintain separate streams of development that suddenly, I’m finding that I can work on several features at once, each separately from each other.  The screenshot above shows a graphical view of the current MMORPG Tycoon 2 codebase.  Right now, I have four different feature branches running, some for core features (“context” is for figuring out how to handle the context actions which I’ve previously shown in a “context matrix”), and some experimental (“duothreadman”, which is doing comparitive performance testing by maintaining two separate pools of threads, so that a glut of low-priority tasks can’t clog up the task queue).  If a feature branch works out well, I can merge it back into the master branch.  If not, I can just delete it and it doesn’t clutter up my repository any more.

Under git, it takes a fraction of a second to create a new feature branch, or to switch from one to another.  These operations would have taken several minutes each under subversion, and been major undertakings which had to be carefully considered and executed.  But they’re trivial now;  not even worth spending time thinking about.  Just make the branch, and delete it later if it turns out to have been a bad idea.

This sort of flexibility means that when I’m feeling blocked on one task, I can easily set it aside and work on a different task, without having to struggle to keep the two sets of changes distinct from each other.  And that’s tremendously freeing.

I had a huge three-page-long essay here a few minutes ago, but I’ve changed my mind about posting it.

Instead, I’m just going to make a prediction.  Please feel free to ignore this post entirely.  It’s just that the last time I made a prediction, it was in a web forum post on TIGSource, and that prediction has long since vanished along with the thread of which it was a part (which is too bad, since the prediction was quite prescient, I feel, predicting the effectiveness of “pay what you want” pricing strategies about six months before 2DBoy turned the indie game movement on its ear by trying it with World of Goo, to spectacular success).

My prediction:

The next big revolution in game pricing, I predict, is going to be realising that the “Freemium” business model (“the game is free, but you can pay real money for extra features”) is unnecessary for attracting a large player base, and actually drives many of the most enthusiastic and dedicated players away from a game.

Specifically, I propose that the core business model behind “Freemium” will work better, without the “for extra features” part of its approach.  Without needing to design around monetization, you end up with better games, and therefore naturally larger player bases.  The larger player bases then result in an even smaller average payment being required per player, in order to cover development costs.

The return of shareware

My assertion is that modern technology and infrastructure has advanced to the point that early-1990s-style “shareware” has become viable (i.e.:  ”here, have this fully functional and awesome game.  If you like it and can afford to help me out, please send me a few dollars.  If you can’t spare anything, then don’t worry about it, but maybe think about it later on, once you’re doing okay.”).  This approach allows a game author to create any game at all, without needing to design monetization strategies which often only serve to fragment the player base, or even raise ethical concerns.  It focuses the author’s priorities exactly where we all know they ought to be:  on making a great game.

This open approach didn’t work in the 90s (in fact, it failed in a fairly spectacular way), because direct payments required people to write checks to somebody whom they’d never met or heard of, and to mail that cheque in the physical post (often internationally) to an address that was in some who-knows-how-old game, and may not even be where the author actually lives any more.  It was just too much bother and too uncertain a process for most people to actually bother with.

But today, game authors aren’t anonymous people who players don’t care about — you talk to them on Twitter and read their blogs and watch them on YouTube.  They’re real people in a way that they never were before, which means that their audiences can and do care about them.  What’s more, we now have this tremendous online payment infrastructure, so it’s no longer such a terrible pain to try to make a direct payment to an author you want to support.

Game makers whom I’ve met

I’ve written before about how when I was young, I decided that I wanted to make video games as a career, and how I made a list of the game makers that I wanted to meet, once I was in the industry.

I met Wil Wright by working at his company for six months.  I met Steve Meretzky at a Game Developer Conference several years ago.  I met Chris Crawford by sending him an e-mail while I was at university, and we had rather a long and interesting discussion about the state of storytelling in games at that time.

The one guy on my list that I’ve still never spoken or written to is Tim Schafer.  But honestly, I feel like I know Tim better than I know any of the others, simply because I’ve been reading his Twitter feed and watching him on YouTube, and hearing so much from him about his family and business over time.

It’s already proven

So my assertion is that the conditions are now such that the early-90s’ version of the “shareware” concept could work today, in a way that it never could have worked back then.  But technically, it’s already been working for a few years with Tarn Adams‘ development of Dwarf Fortress, which is funded in exactly this way.  But Dwarf Fortress is a niche game with a niche audience, and everyone in the industry has been treating it as some kind of special-case situation that couldn’t be replicated by anyone else.  But I don’t think that’s true any more.  All it’d take for someone else to achieve the same success is a really good game with a really big and passionate player base, and an author who strongly and consistently engages on a personal level with the players of the game.

And I think that we’ll be seeing a lot of this in the not-too-distant future.