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.

So it’s Vim‘s twentieth birthday today.  Or yesterday, depending on where you stand vis-a-vis the international dateline.  (screenshot above is MacVim displaying a snippet of the current MMORPG Tycoon 2 codebase)

For those with other backgrounds, vim is a free text editor.  It’s basically an improved version of vi, the original visual text editor.  (vi was the first program which would display your text at the same time that you were editing it)  Another popular old text editor which is still in modern use is emacs.  And the flame wars between vi users and emacs users are one of those eternal debates amongst IT people who have nothing better to do with their time, right up there with tabs vs. spaces (tabs), tabstops (4), little-endian vs. big-endian (big), and Coke vs. Dr. Pepper (just some tea, please, and a little bit of milk would be lovely, thanks).

Functionally, vim is just a text editor.  But it’s a text editor that’s designed around being used exclusively by the keyboard;  once you really know what you’re doing, you never have to touch the mouse at all.  Or even move your fingers away from the home row.  (Don’t touch your arrow keys!)  Once you get used to it, it’s actually substantially faster and easier to get around a text file — or a whole project — this way.  But it does take a bit of practice and research to reach the point where it becomes effortless.

Oddly enough, my first experience with vim was with its first appearance anywhere;  on Fish Disk #591, for my Amiga 500 computer.  Admittedly, it completely baffled me at the time, and I quickly threw it aside to spend more attention on the various games which were (let’s be honest) the main reason I acquired and kept those disks of freeware software.  And it wasn’t until a decade later that I’d re-encounter vim, as I started to play with Linux, where it was one of several “vi-like” editors available (though it seemed to be gaining acceptance as the best of the lot).  I still didn’t use it much, but I at least learned enough to use it as my default Unix editor.  And during my time at Atari Melbourne House, I wrote a few server programs and a lot of perl scripts, all using vim as my source code editor.

But it wasn’t until very recently, when I started poking with Xcode 4, with its major revamp of Mac and iOS coding features, where I finally decided that I really wanted a more consistent interface for writing code, something that would work the same across multiple platforms, and would remain responsive and not inexplicably freeze up the way that most IDEs will occasionally do.  Other people talked about how great the Mac-exclusive text editor TextMate is, and I considered it, but I really wanted something that I could use on any platform.  So my mind went back to vim, and I really dove into all the details that I had only skimmed before.

I would estimate that it took me about two weeks of full-time development using vim to get back to my usual development speed.  And after another two weeks, I was substantially faster in vim than in other editors.  (Of course, I was already familiar with many of the core vim concepts;  others have estimated 1-2 months to become proficient, for someone who’s jumping in cold)

Anyhow.  I just wanted to mention.  Just because it’s made coding so much less painful, again.  Any coders out there, I’d definitely recommend experimenting with other text editors, and see if there’s one that works well for you personally.  Don’t just always use the one that’s built straight into your IDE by default, the way that most of us do.  There are far better tools available out there, if you’ll only look!

Actually, that’s a dirty lie.

Profiling is fun when it shows you something big that’s easy to fix.  Profiling is a lot less fun when everything is equally slow.  But luckily in my case, there was something big to fix.  :)

I noticed the other day that editing roads in MMORPG Tycoon 2 had become extremely slow.  (Well.. actually I noticed that roads didn’t draw at all.  It was only after I fixed them not drawing that I noticed that they were slow to edit).   This was odd, because I have videos of early road editing, where it hardly touched the frame rate at all on a system much slower than the one I’m using now.  So after some profiling, I found that creating their procedural geometry was taking up about 75% of the whole processing time for the frame when they were created.  This was extremely bad when editing them, especially (because they’re regenerated every frame, when they’re being edited, or when the ground under them is being edited).

Those of you who were at Freeplay will remember the part of my talk where I discussed optimising games, and when to do it (or rather, when not to do it).

For those who weren’t there, the tl;dr version is this:  don’t optimise anything unless you have timing numbers that proves it’s slow relative to the rest of your program, and against which you’ll be able to judge your progress.  Ideally, you get these numbers by using a profiler of some sort.  (Visual Studio has one built in, modern Xcode uses Instruments while old Xcode used Shark, under Linux you have gperf, etc)

What I didn’t say in that talk (and which I’ve regretted ever since), is that there’s a second criteria which can make it acceptable to optimise some code, even if you don’t have performance numbers.  Here is that other criteria:

Continue reading “Profiling is fun”