Category: Game Development

My Favorite Failed Game Projects

From a young age, I was exposed to Sierra and LucasArts adventure games, and became completely enamored with Quest for Glory and Space Quest. I’d spend hours exploring every nook and cranny, finding many ways to die along the way.

At some point, I learned about a nifty little tool called Adventure Game Studio, which provided everything a person needs to develop retro-style adventure games. You could map sprites and animations to characters, make people walk around and say things in dramatic sequences, and even build a custom point and click interface from scratch.

Here’s a peanut gallery of some of my failed personal projects. This is not a comprehensive list! There are a number of games that don’t have any assets on the web anymore. I’m actively scouring the web for them, but haven’t had much luck. Keep in mind, the art assets in each of these are pretty unpolished, because game development for me was more of a sandbox where I learned to improve my skills along the way.

Space Quest 3 VGA

Somewhere into my early years of using the tool, I decided to try and collaborate with a bunch of volunteers to develop a VGA remake of Space Quest 3. Because when you’re 15 years old and want to start up a game development team, fan games seem like a great way to bootstrap.

Space Quest 3: The Pirates of Pestulon VGA Remake

The remarkable thing about this is that our development efforts were organized entirely on a forum, and we had no easy way of managing code or assets. It was basically a long process of attaching things to a forum message, pinging the right person who needed it, and uploading archived builds of the game for people to test out.

Eventually, that project petered out, and the upload services for assets all went dead. As a favor, a copy of one of these early builds was held by Steve from Infamous Adventures. Although it’s not the final product of what we released, it does give some insight into the implementation and general art direction.

No One Likes You

No One Likes You (or NOLY for short) was an edgelord comedy game that I developed during my years lurking on the Linsux forums. At the time, I was going through a major breakup with someone, and developing a game served as a welcome distraction.

The premise of NOLY is relatively simple: you’re an emo kid named Peter, you have ultraconservative religious parents that aren’t happy with how you’re living your life, you’re failing at school, and you’re not particularly popular. It’s your last two weeks of the semester, how do you turn everything around?

In a way, the game was meant to be a response to Willy Beamish, replacing the hip kid in a wholesome 90’s family with a depressed kid in a dysfunctional 2000’s one. Same as Space Quest, I constantly uploaded new builds to a forum for people to play with. I actually got pretty far with developing this one, but a hard drive crash led to me losing all of the game data and art assets.

Sojurn: City of Meteors

Sojurn remains a game that I wish I could go back to and finish. Realistically, very little code ever got committed for the project, but I spent a lot of time with plot development and world-building. It served as a love letter to games like Space Quest, but was intended to take a much more serious tone…generally…

Yeah, that’s right. His mohawk spikes go outside of his helmet. His hairgel freezes to plug the holes in his helmet.

The basic premise of Sojurn is that humanity is finally living in space, Star Trek-style…but, economic and environmental problems have effectively caused the Earth to become a toxic wasteland. Human beings have yet to wander out of its own solar system, as technology never advanced enough for interstellar travel. This new society relies largely on mining and barter, struggling to keep the lights on and life-support systems running.

Sprite sheet and character tests.

You play a young man named Billy, a grumpy punk who works for a waste management company. Your mission is to go from station to station picking up trash and toxic waste, fighting sewer mutants and uncovering a huge conspiracy along the way.

Why am I sharing these failed projects with you? Well, truth be told, I still love them for what they were. Game development was a great hobby in my teenage years, and my hope is that one day I might be able to revisit these different projects and maybe re-make them.

The biggest take-away, of course: BACK UP YOUR FILES.

Random Thoughts on Making a Free Software Adventure Game

I’ve been wanting to get back into game development as a hobby for a while – I used to do it years ago, but can no longer rely on Adventure Game Studio as a tool, due to the editor being windows-only with little chance of a port happening anytime soon.

I have been looking at the Godot game engine, which is Free Software and has many powerful capabilities for 2D games. I’ve played a number of game demos with it, and I believe that it could be just the system I need. It’s very different from what I’m used to, and will take a long period of practicing tutorials and building stupid demo games before I start making any real progress anywhere.

I really, deeply, truly love adventure games in the style of the Sierra titles that I played as a kid – these include King’s Quest, Space Quest, and most notably, Quest for Glory. I have spent a lot of time attempting to better approximate the visual styles and the type of gameplay that these older titles used to offer.

I recently had an idea about implementing different cursor modes in a Godot engine. Although I know very little of how Godot’s internal code system works, I believe that I could effectively create different interaction cursors by declaring global variables. Something like:

def cursorMode {
cursorMode() = c

function cycleCursor() {
  if cursorMode(c) = 0 & RightClick {
  setCursorMode(c) + 1
}

else if cursorMode(c) > 5 & RightClick {
  setCursorMode(c) = 0
}

Mind you, I’ve never been a particularly great coder, so there are probably some conventions that I am missing here in one form or another.

The main idea is that you have cursor modes 0-5, which covers Walking, Looking, Interacting, Talking, and Inventory. If a player right clicks on the final cursor mode, the mode variable is reset to the first one.

You could then define interactions with objects in their relative scripts, such as this:

// Rock
object Rock {

if cursorMode(c) = 1 {
  display("You see a rock.");
  }

if cursorMode(c) = 2 {
  display("You touch the smooth, cold surface of the rock.");
  }
}

Obviously, I will need to crack open some books to better understand the semantics, especially in relation to Godot system syntax, but I would be very interested in figuring out how to put these fundamental building blocks together.

Important Update to the AGS Linux Runtime!

So, the other day something rather extraordinary happened for me. I received a message from Elektroshokker, the developer maintaining the Linux port of the Adventure Game Studio runtime. As some of you know, AGS is my tool of choice when it comes to working on retro-styled adventure games, but the editor is largely Windows-only. (It works wonderfully in Wine, however).

Progress has been made with both a Mac and a Linux port of the game runtime, which means anyone can technically take an AGS game and, following the instructions, port it to run in Mac or Linux very easily thanks to the Allegro library dependencies. There is, however, one very crucial problem with the Linux version, however: it was impossible to put into a distribution package and have it work!

The problem itself derives from the way AGS games save and load files. For the longest time, the default behaviour was that the AGS executable would save or load files directly in the folder of the executable itself. Every time the game is launched, it creates a “temporary” save file to start the game at the very beginning.

Now, this is all fine and dandy if you’re running it in an isolated folder that you have access to, but it will not save and load files if it’s in a directory with root permissions under, say, /usr/share/games/$gamename, because it doesn’t have access to save or load files there without creating a huge security hole in the permissions system. The game will not even start, which also means that it will be impractical to package in, say, a .deb package file. Why package a game that cannot run under standard directories, and why package a game that can run, but each user has to install it on a multi-user operating system?

The solution I proposed was a relatively simple one, and I’m overly happy that it was implemented: now, AGS executables will use the standard place most Linux applications save and load configuration files and other data: under the home directory.

So, with the game binary installed under /usr/share/games/$gamename, the game itself will save files to /home/Username/ ./$gamename, meaning everyone wins.

This is particularly important because in a few months, Canonical (the backers of the Ubuntu project) will be opening up the Ubuntu Software Center to third party developers. With the hundreds upon hundreds of great independent titles out in the AGS community, I think this could definitely give a great boost to game development on Linux, and it’ll give users some great titles. Furthermore, the USC is implementing a model in which developers can be paid for their applications, meaning that all of the people doing commercial AGS games can make a quick buck off of Linux users, too.