Not Alone - Developer Review
<- Back to blog | Posted on 15 November 2016 by Adam Summerton
Not Alone was created over the course of October 2016, for the Pixel Horror Jam. This is the first game that I've taken the lead on in terms of design as part of the team, it was a new experience for me and a steep learning curve, but I enjoyed it immensely (minus the occasional breakdown when the AI simply did not work). The project was ambitious from a development perspective given the limited time scale and my experience, I'd never attempted anything like this before. It features a creature that tracks the player through a spaceship, but only through the dark areas - it flees from the light. The end result looks and sounds great thanks to the hard work of James and Adam S. but is flawed from a design perspective, last minute bugs caused everything to grind to a halt and we just scraped over the finish line.
I've since been working on a post-jam version of the game which has been delayed repeatedly by life but is coming along nicely and I hope it will be a slightly better implementation of the core idea. For me the experience was more important than the end product though, Adam S. has been our primary developer and designer for the majority of our games and I'd been keen to get involved more in the design and development aspects as my role usually encompasses art-related tasks. I've wanted to learn more about designing games through practical experience, and the best way that I can summarise the whole thing for me is that it scratched an itch. You can play Not Alone on our games page, or on our ich.io site Here. Below is a more in-depth look at the design and development process.
I learned a lot about design and motivating the player throughout the project. It is one thing to have an idea, and another to actually make it enjoyable. As the game stands there isn't enough encouragement to get the player moving out and around the ship, most rooms are empty and don't have meaning to the player. This wasn't the original intent, I had intended to include all kinds of fanciful systems around the ship (similar to FTL), I wanted there to be shields (to deflect incoming meteor storms but which drained the power heavily), I wanted there to be a med-bay, power conduits and so on. I wanted the situation to feel like you were on a ship that required a crew to function, but that crew was gone and only you were left… how were you going to manage? As it is, you can mostly just stay in one room for the duration of your trip. Systems went unimplemented because the core technical challenges (the creature and the lighting) took up the majority of my time right up until the deadline. The post-jam version will not feature all of my ideas, but there should be a couple of extra systems to encourage the player to get moving and explore the ship more.
Additionally, it turns out that trade-offs are easy to think up but hard to balance in practice. The lights in the game make you invincible, they prevent the creature from coming anywhere near you. Needless to say, something that powerful should come with a serious handicap. The two handicaps that I introduced were faults and power drain. Too many lights on would cause serious power drain, and even potentially power overloads. Lights would also develop faults after a while and break down which would then mean the player had to take time to repair them. Balancing this so that players didn't overuse lights proved to be a challenge, and I feel like more training is required at the beginning of the game to slowly introduce players to managing ship systems and also to provide a bit of a buffer before they are thrown into the action.
The AI for the game, if it can be called that, was the most complex part of the development along with the lighting system that it’s linked with. The game was developed in Construct 2, I've had mixed things to say about it in the past, but it has come a long way and for the most part I did find it a pleasure to work with this time around. I'd still like to be able to type out code, but Construct 2 has some acceptable compromises in that respect, however, the sharing of events between projects absolutely needs to be improved in Construct 3. With a state-machine plugin, the built-in pathfinding and the debugger my task of implementing the creature behaviour went from "never going to happen in the time limit" to "you'll weep bitter tears before the end but you'll get it done." That's a big deal. It did make the entire game achievable in the time limit and within my own personal time constraints.
The lighting system works thanks to the blend modes available in Construct 2, I had figured out quite early on in development how I wanted to create the effect but actually making it happen is always a different story. I worked through a number of small prototypes with simplified scenarios to help me work out how it would actually function, games are very complex sets of interacting objects and systems and it is helpful to reduce that complexity right down when problem solving. For me, using a divide and conquer approach by separating out technical problems and working on them in isolation is a useful way to begin, I can then focus on integrating solutions and getting them to play nicely together.
Whilst creating the lighting system and trying to get it to work with the creature AI, I was reminded several times that it is often helpful to centralise some core functionality. As an example, the creature pathfinding needed to be blocked from entering a room that was lit, but it also needed to allow for the creature to flee a room that had been dark but had the lights turned on whilst the creature was in it. Essentially I needed one-way pathfinding areas, where an entity could move out of an area but not into it. This isn't (as far as I could tell) something that was built into the pathfinding behaviour in Construct 2, so I needed a system that would create these blocks and recalculate paths depending on where the creature was located.
My first attempts were riddled with bugs, as I tried to create appropriate blocks only around a specific doorway and only when a light turned on or off. Due to the fact that lights could potentially flicker and switch off by themselves at any point and the player could switch them on/off as they pleased, an unpredictable set of interactions would occur leading to all sorts of lighting bugs. The solution was to centralise the whole process, so that one function was called once per set interval, this function would loop through all doorways and ascertain what state they should be in depending on the condition of associated rooms. This was very stable and worked as intended but performance was poor as this one function was looping through all doorways at once (the old code was only doing it where necessary). This is really the ideal first step: get it working first, then optimise later. I then went through using the profiler, some logical thinking and some experimentation and made that centralised function much more efficient.
Artwork & Animation
James: Being a big fan of anything to do with space and spaceships I enjoyed doing the artwork for this game. I feel I was successful at creating a run-down sci fi theme. There was a lot less animation on this project than what we normally do, so I had more time to spend on other things. I was happy with the engine design and feel of the ship, if I had more time I would have liked to do more machinery and general interior items.
My main aim for the design of the monster was to create something very alien and scary, I don't feel I totally accomplished this. If I could do it again I would experiment with some more unusual movement and animation instead of a traditional walk cycle, something that seemed more alien and a little disturbing. Some things that I would improve on are:
" I would have liked to be more experimental with the monster walk cycle and design.
" Pushed the scenery/item design to include better alien elements.
" More environmental animations/bursting steam pipes/things breaking to create a better sense of tension.
Adam D: I was very pleased with the overall look of the game, I felt like James' designs perfectly captured the feel that I wanted. I contributed the HUD and a few other graphics such as the doors and effects. The combination of James' graphics with the lighting effects worked as well as I'd hoped, I agree that it would be nice to keep working on the details of the ship and make it feel like it is seriously damaged with sparks flying, warning lights and smoke. For performance reasons I had to go easy on the particle effects, it would be nice to see a few more in the game to enrich the atmosphere though.
Music, Sound & Additional Development
Guest Paragraph by Edge
As Adam D mentions, this was the first major project we worked on where I wasn't taking the lead, and this led to an amazing game jam experience for me… when the inevitable game breaking bugs hit at 1am, I just shrugged and went to bed. It was an uplifting experience that I fully recommend.
The other great thing about Adam taking the lead was being able to concentrate solely on music and sound. I have done the soundtrack for all 16 of our previous games, and it's something I really love doing, but it's always a bit of rush to do it alongside development during a game jam. With Not Alone I could just take that extra time to put together music that really fitted the atmosphere of the game. I fell back on my normal workflow of using GarageBand for iPad, which again drove me mad and left me swearing to myself that I would invest in a proper setup for the next game jam (this is not the first time and won't be the last). Despite the flaws, GarageBand allows for quick and easy composition of electronic music, and after recently binge-watching all of Stranger Things I decided to write a little homage to the theme tune, but with some slight changes to make it sound more like it was in space. I'm not sure how successful that endeavour was, but I was really pleased with the end result and thought it fitted the visual aesthetic well.
With music out of the way I did something I'd been wanting to try for years, and indulged in a bit of actual sound design. We needed some creepy alien sounds for the creature, and I decided to try out a crazy idea I'd been toying with. I set the iPad up to record sound through the microphone directly into GarageBand, and asked my long-suffering wife to hold it slightly above the coffee machine and press record. I then made myself a cappuccino, but spent a lot longer than normal messing with the milk frother, trying to open the steam valve in such a way as to sound like a terrifying monster. Amazingly, after adding a little reverb the end result was pretty monstrous and made it into the final game as the alien's battle cry.
Later on in the jam a request came in from Adam for a ship's computer voice, he pointed me towards a Text-to-Speech site and said "like this but cooler". This was a fun challenge! I started by changing the voice profile on the text-to-speech site to a posh English lady, and reducing the speed of the speech to as low as possible. This worked fairly well for the dynamics of a robotic computer voice, but it still sounded very flat. I entered in all the required phrases and saved them all as MP3s, then imported the MP3s into an audio editing application. I added 4 duplicate tracks, giving 5 simultaneous voices saying the same lines at the same time. From here I messed about with panning and effects, and the tracks ended up with varying degrees of reverb, distortion, chorus and tremolo (with the flat audio remaining on the centre channel). I tweaked the variables for a while until I ended up with the voice you hear on the final game, which I have to say is so much better than I ever thought it would be.
Other than the audio work, I also got to do some proper playtesting, which is a stage we always leave out of our game jam entries (mainly due to time constraints). James & I (along with guests Pete & Dave) all contributed to the play testing, and it became obvious just what an important part of the process it is. We saw massive improvements in every build, often directly based on our feedback, it's something we really need to try and do more of on future game jam entries.
Final Word from Adam D
Not Alone is hopefully the beginning of me doing more design and development for the team, by just giving it a go you can learn so much. It is a step in the right direction, I think I need to finish off a post-jam version to feel fully satisfied that I did the best job I could for my part and so I can move on to other projects. We've done a lot of games together and, although Not Alone may not be our best, I'm proud to have a project up there that I developed and took the lead on. I'm proud of the work that the other team members put into the project, it wouldn't have been submitted without their effort and support, there were excellent contributions from guest team members Pete and Dave too. So I'll finished by thanking the rest of the team for their help, and thanking my partner Coraline who kept me sane through the last few hours of the jam.