Atop, a week in review

blahblahblah
I was intending to write this earlier, but it just never quite seemed like the right time to sit down and write.

This is sort of a post-mortem on Atop.  “Sort of,” in that I may return to it someday.  Actually, let’s strike that.  This is a post-mortem.  If I do continue with Atop, it’ll be under a different name, and it’d appear under the “Full Games” category on the sidebar.

“Atop” is the first ‘clone’ game I’ve ever done, where I’ve consciously taken another game designer’s work, whole cloth, and tried to replicate it as closely as I could.  I had good intentions here — it’s a very old game, but a very important one, and it’s one which cannot be played on modern machines without the help of emulators — which usually means pirated copies of the software.  I’d assert that from a historical game design perspective, it’s as important a design as, say, Elite.  And I really wanted to be able to point people at an implementation of the game that they could play with to get a feel for what the game was about, and why it’s important.

So my intentions were good.

But I’m really not thrilled at completely copying a game design like that.  It’s much too close to my personal “ethical behaviour” boundaries, and that really killed my enthusiasm for completing the game within the week.

On the last night before the deadline, I was convinced that I was going to miss the deadline — that there was no way to finish the game in time.  In practice, I made it by removing progression (ie: making it a single-level game), by leaving out sound, and by leaving out any of my usual framing around the game (intro sequence, preferences settings, credit scroll, etc).

There were also bugs in both the OSX and Win32 builds which were initially released;  the OSX build was looking for libraries in an incorrect location, and the way that I was capturing the mouse made it impossible to move the game window in the Win32 build.  Both these issues have been fixed.  The Win32 fix was a library problem;  the bugfix is in latest trunk of the Vectorstorm codebase on Github.

The OSX fix is a harder problem.  I haven’t yet figured out the right way to fix it;  it will affect every OSX build of any Vectorstorm project I do (or anyone else does) until I figure out the correct fix.  (If any of you are cmake experts, send me an e-mail!)

Anyhow, with that out of the way, here’s the post-mortem:

What went right

Graphically, the game came together very quickly.  I was able to swipe a lot of code from MMORPG Tycoon 2, most notably including the sky, the water (with a few modifications), and the system for procedurally generating models, which is being used for all the objects which sit on top of the island, in Atop.  I’m very pleased that the visuals give me a similar feel to what I remember from playing Sentinel on an Amiga computer, back in the day.  The “transition to new body” sequence is mimicking something I vaguely remember from a remake from about ten years ago, which doesn’t seem to exist any longer.

The game rules themselves were implemented almost exclusively inside the “Map” class.  If you ignore the other bits of the code, the codebase actually looks a lot like a pure C game, with hardly any OO abstraction at all.  I’d forgotten how quickly you can throw things together, if you’re not busying yourself fitting abstractions over everything.  (By contrast, MMORPG Tycoon 2 would be very, very difficult to develop that way, as it’s a substantially more complicated game)

One thing I’d always felt was a weakness of The Sentinel was not knowing where the Sentinel was looking.  Early on in development, I added visual indicators to the game so that you could see the sentinel’s vision cone in the world.  After several plays, I realised that the change made the game less fun;  that part of the tension of the game was having to divide your time between working to absorb and climb, and looking over toward the distant sentinel and trying to gauge how much time you had left before it saw you.  By just drawing what it could see onto the ground, that tension suddenly vanished.  I feel like noticing this and taking the feature back out again was really good exercise for my inner game designer.

The game showed up a lot of bugs which have crept into the Vectorstorm library over the past year.  These include things such as temporary display lists being rendered with an incorrect transform matrix, and vsMeshMaker  objects being happy to merge vertices even if they are of different colors. These bug fixes are all now in the public Vectorstorm trunk.

What went wrong

It took me far too long to decide what I was going to do.  For a game where I decided to use a wholesale copy of someone else’s design, I really shouldn’t have spent the first four days trying to pick a topic;  I could have started right from the get-go.  When I first started the week, I started on a 3D physics-based game which required a controller for input.  And I bought a new controller to do that, and installed a driver to use the controller.  And the driver took over my computer such that after connecting a controller, no mouse would work again until rebooting the machine.  And the driver came with no uninstaller.  It took me a good day or so to get the machine back in proper working order.  Lesson: do not install new hardware during Game In A Week.

It’s actually been a very long time since I played The Sentinel, and my memory of its rules probably isn’t exactly right.  There is definitely a bug in the AI in Atop, which allows the enemy to attack you whenever it can see you, whether or not it can see your square.  According to my memory, it should only be able to attack you if it can see your square.  (This is probably a case of the enemy doing a vision check against the wrong point.  I didn’t notice the bug until a few days after release)

The lack of level progression is a major problem for Atop.  Part of what made the game work so well was the mechanism for moving from level to level.  The idea was — there are 10,000 levels in total.  When you complete a level, the amount of energy you have spare will determine how many levels you skip.  So if you did really well in a level, you might skip 20 or 30 levels.  Or if you only barely snuck through, you’d have to move on to the very next level.  It gave motivation to try to have the highest possible energy before absorbing the sentinel.  Which is a motivation that is completely lacking in Atop.  Lesson:  Allocate and plan time for metagame;  don’t leave it as a detail to be implemented at the last minute!

In the original game, if the sentinel could see you but not see your square, it would create a “meanie” from a nearby tree, and the meanie (if it could see you) would force you to hyperspace.  I never liked this rule.  It feels like an ugly hack to deal with that situation.  It’s a bad situation, the “what do we do if the sentinel can see you but can’t legally attack you” situation.  I don’t know what the right thing to do in that situation is.  And this situation doesn’t come up in Atop since (due to a bug) the Sentinel just attacks you even if he can’t see your square.  But I really would have liked to have found an elegant way to handle this situation.

Final thoughts

It seems like making a non-trivial 3D game inside a single week is a stretch for me.  I barely managed this one.  The last one, “Lord”, took me seven weeks to finish, and was basically unplayable even then.  Additionally, I now know that working on ‘clone’ games — even ones which I have affection for — is somewhat demotivating for me.  I suspect that I’ll not be doing that again.

Tomorrow, I’ll actually post some things about the development that’s been ongoing on MMORPG Tycoon 2, honest!