VectorStorm Blog

I own a Kindle.  In fact, I own two.  This is not, in itself,  relevant to anything in this blog post, except inasmuch as most of my new book acquisitions over the past year or so have been in electronic format.  Electronic book readers are fantastic for making it convenient to lug otherwise heavy hardback books around with you, and also for avoiding the exorbitant prices charged for physical books here in Australia.  But sadly, they are not very good for leafing through at random.

This has made it somewhat awkward for me, because I’ve established through long tradition that the topics for my “Game in a Week” games are selected at random from books.  And I don’t really have a good way to pick a random topic from an electronic book.

So once again, I’m returning to my (overflowing) physical bookshelves, and feeling guilty about the few dozen books on (, around, under, or vaguely near) them which I still haven’t actually sat down to read.  But I’ve picked out an old favourite which I haven’t used for a GiaW before:  ”Sherlock Holmes: The Complete Facsimile Edition”.

This book is a little special for me.  I’m a big fan of Sherlock Holmes, which probably doesn’t surprise anyone.  But more than that, this was the first book I purchased after moving to Australia.  I bought it in a tiny book shop (sadly, no longer existing) halfway between the train station and my workplace.  It’s bound up in an ill-fitting dust jacket of clear laminate (which is clearly handmade), and the front still bears a large green sticker under that dust jacket reading:  ”Wordsworth Editions:  Only $14.95 RRP.  Quality & Value”.  On the back is a (much smaller) shop sticker, which prices the book at $8.67.  Which is actually a pretty good value for such a hefty book, here in Australia.  And it contains facsimiles of the original publishings of every Sherlock Holmes story, complete with typesetting and illustrations.  As this is a paperback book containing facsimiles of much larger pages, the reproduced print is quite small, which can make it a little tricky to read.  But I did read the whole thing during my commutes, many years ago.

For those who care about such things (anyone?) this edition was published in 1996 by Wordsworth Editions Ltd,  ISBN 1-85326-896-8.

So, just to go over the self-imposed rules once more:

1. Topic is chosen at random from a book, by opening the book at a random point.  The first full sentence completely on the left page and not containing any proper nouns (character names, place names, etc) provides the words which may be used in any way to construct a topic for the game.
2. All design and coding work must occur within the 1 week deadline.  It is legal to select the random sentence from a book on the night before the week begins, but I am not allowed to start designing the game until the week has actually begun.
3. The first release of the game must be posted by midnight (local time) at the end of the seventh day.  After that time, no further modifications may be made (apart from critical bug fixes, such as crashes or rendering glitches).

So, I have opened Sherlock Holmes at random, and have hit pages 334-335.  This is a few pages into the short story “The Adventure of the Stockbroker’s Clerk”, at a point where this stockbroker’s clerk is relaying a story to Sherlock Holmes about being tested on his knowledge of the current value of particular securities, in preparation for a lucrative (but slightly suspicious-sounding) new job.

So with that context explained, the randomly selected sentence for this GiaW is this:

” ‘ A hundred and four.’

Note the double-quoting;  this is Mr. Hall Pycroft telling Sherlock Holmes what he said to someone else.  I don’t imagine that this subtle grammatical nuance will be important, but I’m at a bit of a loss over what to do with this, and so I’m grasping at straws.  There isn’t even a verb or a noun for me to start designing from!  This is the first time I’ve had such a tiny sentence to work from, and I’m not entirely certain how I’m going to manage to make a game inspired by this.

But luckily, I’m not allowed to think about it tonight anyway, and so I won’t.  Game in a Week #8 begins in earnest tomorrow.  Come, Watson;  the game is afoot!

The final game will be posted in this space before June 20th.

First and foremost:  I’ve put up another update to GoGoGo!.  If you were having crashes or etc, go grab that.

Technical stuff follows:

In computer graphics, the scarcest resource is currently (usually) communication time.  That is, you only have a certain amount of time for the CPU to deliver data and instructions to the graphics card, if you want to maintain your frame rate.  These days, that communication time is far more of a limiting factor than how many polygons you’re going to draw or how many pixels you’re going to be touching.

Back in VectorStorm’s early days (say, up to about Game in a Week #5), I wasn’t actually drawing enough for this communication speed to be a big issue;  it was just a few dozen lines, for the most part.  I could just naively send them to the graphics card every frame.  Easy.  But as my games have started drawing more and more — triangle meshes, textures, etc.  It has begun to become more and more important to optimise the communication.

In OpenGL, the usual way to do this is with Vertex Buffer Objects (VBOs).  Basically, these are just a way to store data directly on the graphics card.  So instead of needing to send a hundred vertices to the graphics card each time you want to draw them, you can instead just say “Draw the hundred vertices that I already put into VBO #1.”  Much faster to transmit, that way!

The tricky problem, of course, is that OpenGL will typically need to be restarted in the new resolution, which means that all of that stored data on the graphics card needs to be sent up again.  And I was forgetting to do that for VBOs.

The funny thing is that this bug has been in the code ever since GiaW #6, and has affected several released games in the time since then.  It’s just that none of them have actually presented an interface which allowed you to change the screen settings while the game was running.

Anyhow, I have this fixed now.  Fullscreen and changing resolutions from the Options screen should all now be working again.

Similarly, the formatting issue on the Options screen was related to VectorStorm not knowing how to build a bounding radius around data which was stored inside a VBO.  Since it didn’t know how big the different pieces of text were, it didn’t know how to keep the different pieces of text from overlapping.  I’ve now fixed that issue as well, so the options screen is correctly formatted again.

Just goes to show how adding a single new feature (VBOs, in this case) can break a whole bunch of old things that used to work properly.

(Note to self:  Must fix textures to be re-uploaded to the video card when a resolution change happens, as well.  I’m getting away with not doing this right now because there are no textures in the game mode where you change resolution/fullscreen, but that won’t always be the case.)

So, some discussion on GoGoGo;  what went well, what didn’t, and what I’ve learned from the experience.

As I mentioned before, Increpare proposed an end-of-year game jam (link to his game), and I absolutely jumped on-board.  I’ve been sitting out of most community game-making events for the past year or so (TIGSource competitions, Ludum Dare, etc), and I really shouldn’t have been.  Felt really good to be taking part in something again, and actually kicking something out the door in a reasonably timely manner.

Many years ago, I spent a summer working at a spot called Virtual World (we had 24 of the mark 2.0 cockpits — quite old even when I was there!).  It was good fun;  get good at a couple of video games, train others to be good at them, some light maintenance, awesome co-workers, etc.  One of the games there was a game called “Red Planet” (training video link — haven’t seen this in ages, but sure enough, someone’s put it up on YouTube!  I love the Internet!  I used to see the last few seconds of this every ten minutes, as the next group of players were coming out of training), As you can see in the video, this was a game about a race between hovercraft in mining canals.  Its vehicles had really interesting handling;  you could slew from side to side, turn left and right, and control your altitude (but not pitch up and down).  The lower you were to the ground, the faster you’d be able to go.  And, of course, there was a limited supply of rocket boosters, which once lit, couldn’t be stopped.  Also, these graphics were pretty cutting edge, back in those days.  It’s hard to believe, looking at them today!  But I’m a cranky old programmer, now.  You kids, get off my lawn!  :)

Anyhow, ever since then I’ve kind of missed that game.  I’ve always played around with the idea of making my own variant of it.  And so here I thought, “Hey, I could quickly throw together some vehicle handling, make some procedural tunnels, and give people a “distance” score, like Canabalt and similar ‘how far can you go’ games.”  The idea was to take the procedural model-building code from MMORPG Tycoon 2, and just use that to easily build mining shafts to fly through.

Plus, it’d give me a chance to write a really neat vehicle-following camera.  Vehicle-following cameras are really tricky to get right, and I haven’t gotten to make them very often (my last one was for the racing segments in Viva Pinata: Party Animals), so it’s an area that I’d like to get to practice more often.

Continue reading “GoGoGo, a post-mortem”

So about ten hours ago, Stephen “Increpare” Lavelle invited me to take part in a “New Year’s” game jam, with the goal of finishing a new game in the few hours before the new year.  (Of course, I had to be creative with time zones!)

How could I possibly refuse?  And of course, the title that immediately sprang to mind with such a short time limit was “GoGoGo!”  So I ran with that.  Hope you enjoy.  it’s available in Win32 and OSX flavours from the sidebar.  (Picture completely unrelated, apart from the coincidental title text)

(Update:  1.0.1 is now out;  fixes the Option screen crash and the Mac framework issue.  Further discussion when I’m awake!)

First, I would like to say that I’m not entirely happy with Lord’s state.  It has a lot of things wrong with it that are immediately visible to anyone who plays it;  the pacing is the biggest offender here, I think I totally failed to convey the feeling that I was striving for.  But that’s not such a bad thing;  the point, after all, of trying to make a game in a week is to finish a game in a week, not necessarily to have a fantastic game at the end of it.

No, the chief failure of Lord was that it took me more than 7 days to complete.  In fact, it took me 77 days to complete (that number wasn’t planned).  This is the story of what happened, in the hopes that telling the story will help me keep it from happening again.

It was the day after Christmas, 2008.  Picture a younger me, more hale and hardy, his cheeks still flush and aglow, strong in limb and body, his hair not yet gone grey.  Flush with his youthful vigour, he thought, “Why, it’s been a long time since I’ve done a Game in a Week.. and I have a full week of vacation left before I must return to work!  And work will be quite busy, so I should have fun now while I can, for I will not be able to consider a Game in a Week for a long time into the New Year!”

More beneath the fold.

Continue reading “A Long-Awaited Post-Mortem”