Take control of an alien abductee as you try to escape from the confines of an alien spaceship. This would be hard enough without the tranquilizers they keep you pumped full of. Every time you wake up, you have but 30 seconds to make a break for it before the drugs kick back in. You can explore your memory of the ship in between runs to learn more about your captors and plan your next escape attempt. Use the items scattered about the ship to aid in your escape, and overcome the obstacles how you see fit. Find the key to open the door, turn off the hydraulics and pry the door open, or go around it by crawling through the vent to the next room and smashing the glass door in between. There is no single solution to any problem.

Post news Report RSS The Final Sprint

I reflect on the project as a whole, announce the reason for the slight delay in release, and talk about what a week it's been getting ready for release.

Posted by on

This past week has been a busy one. I was hoping to have In Vivo available for purchase by the 12th. The bad news is that doesn’t look like it’s going to happen. The good news is that the game is actually 100% finished with development. I still have a bit of testing to do, and some marketing materials to create, but the game is done being developed. The rest of the work shouldn’t take more than a night, but then I still have to submit the game to the various distribution platforms that I want to put the game on and wait to hear back. I’ll be honest in saying that I have no clue how long that will take, but I’m optimistic that it won’t take too long. So while we all wait, let me regale you with a quick look back at this project, and some details about what went into this hectic week.

Setting a deadline

When I first started this project back in September, I gave myself a very short deadline. I thought I could take a 48-hour game jam game and turn it into something commercially viable within a month. Are we all done laughing now? Ok good, moving on. I figured that with the core prototype finished, it shouldn’t take very long to finish the game. All I had to do was add a bit more content, one or two more gameplay features, and polish everything up. I didn’t finish even one of those things within a month, and looking back I don’t know how I ever thought I could. Part of the reason behind the deadline I set was because I was moving across an ocean at the end of October, and I knew that if I wasn’t finished before the chaos of that set in, I wouldn’t likely get a chance to really dive into it until December. While that was true, and I did have almost a full two months where I didn’t work on it at all, in my head I honestly believed that I could deliver the features that I wanted to in that time frame.

How the game originally looked. No animations, just the player sliding around. It was pretty awful, really.

How the game originally looked. No animations, just the player sliding around. It was pretty awful, really. Why did I think I could turn this into a real game so quickly?

Deadlines are good. When used properly, they are an awesome tool to help get something done and refine the design of your product to make it as focused as possible. What I did was not a proper use at all. I made almost no compromises with what I wanted the game to have, and I didn’t make a realistic estimate of how long it was going to take me to create that product. I just threw ideas on the page and picked a random date on the calendar. It’s no wonder I didn’t make that deadline. When I came back to the project after getting settled in at the new house, I made it a personal goal to get the game released before April. This decision was much less arbitrary; I actually took estimates of how long various parts of the game had taken me, how much was left to do, and accounted for time lost for things like me having no idea how to record sound effects. As it got close to release, I got excited and jumped the gun. I thought I would be done by the 12th, and it looks like a bit of crunch this past weekend made that possible, but having a finished product and being able to actually sell that product are not the same milestone. So much of making an indie game has absolutely nothing to with the game itself.

Oh how far we have come

I feel like I’ve been doing a pretty good job for the past couple of months in sticking to a good schedule with this project. I’m a programmer by trade, and since agile is pretty popular in programming circles right now, I decided to try and adapt some of those principles to my game. The most important and rewarding of those was the time boxing. Setting up a weekly deadline helped me focus on what was important and deliver something playable on a consistent basis. It was an amazing feeling to know that at any given time, whomever I was talking to and whatever the circumstance was, I could point to a link on my website and let people try a functioning version of the game. Motivation went through the roof with that; it stopped feeling like I was alone in my office slaving away at something, and more like I was courting my potential customers. It also got me more feedback than I ever could have hoped for if I had waited to deliver something closer to the end product.

Fitting that the room that started it all would make it into the final release in some form.

I know this image was in last week’s post, but it really shows how far the project has come to see this right after seeing the original. Plus, it’s my blog, I do what I want.

It’s a good thing, too, because this game was not fun. I’m not being self deprecating here; the interface was clunky, the controls were awkward, and the play was punishingly difficult. Having the ability to take that feedback, iterate on it for a week, and present the changes to an audience really helped me refine the product. I would have loved to have more feedback, or even the same people making comments from week to week, but without the comments I got, I know this game would be a hot mess right now.

Chaos ensues

Last Monday, with the March 12th deadline fast approaching, I set myself into a crunch period, of sorts. I had a lot to get done just to finish the game in that time, and I wasn’t sure if I could really do it. The core mechanics have been done for some time now, and these final weeks have been focused almost entirely on content, with the occasional tweak or bug fix. Unfortunately for me, I am awful at content generation. I spent the first several years of my hobby time creating engines. My code is riddled with small, pointless optimizations using things like bit-wise operations, and every file format that this code creates is entirely custom and written at the byte level. I’m sure JSON or something else would have been fine, but I do these kinds of things without even thinking about it. Designing a level though? That’s much more difficult.

I’ve known for a couple of weeks now that I was going to need two maps. One for the demo, based on the layout of the original map in the ludum dare version of the game, and one for the commercial product. The map for the demo was relatively easy, since I already had a structure to base things off of, and it is pretty small. The main map is roughly four times the size of the demo map, and it has a lot more going on. The demo map only took me a few days to finish, though it had been started and significant work had already been done on it. I really had no idea how long the full map was going to take. I cleared my calender for the entire week and just tore into it. While I’m a bit exhausted from the lack of sleep and the hour of my life that daylight savings stole from me, I think it was extremely productive.

Besides, what good are my level designs if the players can just move things around as they see fit?

Besides, what good are my level designs if the players can just move things around as they see fit?

A different approach

One of the key goals I had for this game was to make sure that every puzzle had multiple solutions. In the ludum dare version, many people complained that they would never have figured out how to beat the game because some of the steps made no sense to them. Certain tools could only be used to interact with certain objects, it was all very reminiscent of the old Sierra adventure games. With what I have now, there are simply a handful of tools at your disposal, and a map in front of you. I made sure that each goal can be achieved in at least two different ways, and in many cases that number jumps up to five or more.

Making that all work from a mechanics perspective was easy. I broke down each tool into a set of traits, and tagged each object with how it reacts to each trait. From a design perspective, making sure that the tools are available where the player will need them, and that each upgrade is sitting behind a series of obstacles that can all be bypassed in multiple ways was a nightmare. In some of the earlier puzzles, this took some serious tweaking to make sure it was possible with the tools the player had at the time. I was surprised, however, at how much easier that got as I moved to the later parts of the map. Once you have the ability to consistently dodge the guards and create distractions, almost any puzzle can be approached from at least three angles.

One of the primary functions of the living area of the ship is providing players with alternate means of acquiring the necessary keys to proceed. Plus drugs.

One of the primary functions of the living area of the ship is providing players with alternate means of acquiring the necessary keys to proceed. Plus drugs.

In the end, I’m pretty happy with the map I have. I’m sure more playtesting would make it better, and I’m almost 100% positive that it will get ripped apart if it ever gets reviewed. None of that matters though, because I have taken a game from concept to market-ready product for the first time in my life, after years of dabbling and making unfinished prototypes. No more will I have to try and make excuses when people ask to see some of the games I’ve worked on. I’ll just point them right here. Now all I have to do is figure out how the hell to actually get this thing into a store.

Comments
rsdworker
rsdworker

looks good so what happen after release? like you do anything to game? or start new project?

Reply Good karma Bad karma+2 votes
empyrealhell Author
empyrealhell

I did come up with another game mode that I could add pretty late in development, similar to the challenge maps in portal. Basically just a series of short maps with a focus on one mechanic that you can play against the clock. Since it doesn't affect the core of the game I decided to push the game first and add that after the release, so I will probably start work on that after the release.

After I finish that, I have a couple of ideas for potential projects after this one, but I'm still not 100% sure which one it will be.

All of that said, I think after release, I'm going to take a break for a couple weeks. This will leave me free to fix any emergency bugs that make it into release, focus on marketing the game, and generally to relax for a bit as this has been quite an exhausting experience.

Reply Good karma+2 votes
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Icon
In Vivo
Platforms
Windows
Creator
empyrealhell
Engine
libGDX
Contact
Send Message
Release date
Game watch
Follow
News
Tags
Release
Browse
News
New
Post news
Report
Report
Share
Related Games
In Vivo
In Vivo Adventure
Related Engines
libGDX
libGDX Commercial