How (not) to develop a First-Person Adventure Game

It’s probably never good to start a blog post being shocked at the date of your previous post, but given that somehow 4 years have passed some mild shock is probably to be expected. How can this be? Where has the time gone? Etc…
So, in those 4 years lots has been going on, but nothing I was especially ready to, or in a position to share.

About five years ago I started working on a ‘simple’ 3d puzzle game for mobile devices, my thinking at the time was, “OK, so the app stores are now flooded with me-too 2D apps, how can I stand out? I know, I’ll do something more challenging in 3D”. Famous last words… Everyone knows that 3D game development is an order of magnitude more complicated and fiddly than 2D games, so I was gambling on my experience as a developer to compensate for the extra effort and to help me get a game out quickly. What I didn’t take into account was getting ideas of grandeur, with influence coming from other games I would soon be contributing to…

So, during the summer of 2012 I took some time to consider which SDK to use to develop the puzzle game in, I had my own full PC based 3D game engine which I toyed with porting to mobile, I had a minimal (let’s call it a) game framework based upon the Imagination Technologies SDK (so enough there to manage and draw 3D assets, but not much else), I had my previous Objective-C based iOS apps, then I investigated UDK, and finally settled on Unity3D.

Unity had the advantage of being accessible and quick. UDK offered a technically stronger platform, but wasn’t very useful for mobile devices, and was very inflexible being pretty much hardcoded around FPS games, which my idea could stretch to, but platform flexibility was just going to be too limiting. The power of Unity, which was on version 3 at the time, was that I could try out and prototype gameplay within 7 days of using the engine for the first time – that’s 7 days only working in my spare time too. Such was a joy, I had a really quick response to my ideas, I could try things out and the engine made things really easy, not getting in my way at all. The only real downsides at the time were performance, Unity 3 was really really slow, and C#, I could feel my intelligence wasting away as tasks I was used to dealing with manually were all being dealt with under-the-hood. Don’t get me wrong, the ease of C# was just great, I could do anything without having to think too hard about it, the problems came later, when I returned to ‘real’ programming and suddenly my C/C++/Assembly brain had left the building.

The idea originally was to implement a basic game, based around navigating an open outdoors space, trying to avoid an AI based baddie, while getting to a safe place. I don’t want to go into any more detail than that at this point, as I’m still working on the game, and I hope I might eventually finish it. The focus of this post is the feature creep, that even an experience developer – who knows better – can still experience, mainly as a result of working alone and therefore an excessive amount of time passing by, and expectations shifting.

The aim was to produce very few assets, that could be configured to create simple puzzle spaces, that when navigated in a first person, using drag to change view and tap to move on a mobile device, would create an interesting challenge around ‘where are you looking’ and ‘can you sprint safely to that location’. At the time, even such a basic premise, being in 3D, and some of the free bonus atmosphere of a horror ‘lite’ theme, might have stood out a little on devices that lacked 3D games content.

I quickly discovered that the landscape rendering in Unity 3 was terribly slow. Far too slow for the ‘mainstream’ mobile devices I wanted to target at the time. But by this point I’d got into the idea of using Unity, and I enjoyed the responsiveness of the engine to allowing me to implement my ideas. While testing on PC the landscapes rendered just fine, so here we trigger my first shift from the planned course! A shift to PC made some sense, there were indie stores opening up online, everyone else had gold-rushed to mobile now, so maybe there would be some space on PC again?

So, with a PC focus, I could not explore getting the most out of Unity’s landscape rendering, which now appeared a little too basic for a PC focussed title, so I invested in World Machine to generate more realistic terrains, and an off the shelf shader to save me some time bringing that content in to the game. I invested in some vegetation models, an autumn themed kit, which again gave the visual quality a boost for a PC focus, and offered game-play shifts away from some of the original puzzle aspects, but providing foliage that could block line of site to the AI. Even playing such a basic prototype, with simple AI, but broken lines of sight actually worked much better than I’d expected. Even playing my own prototype game, I had a strong sense of fear for where the AI character might be, not bad for such a quick implementation, the potential was clear.

Around about the same time this was going on, I started to get involved with The Chinese Room’s projects, initially Amnesia: A Machine for Pigs, and later Everybody’s Gone to the Rapture. Being involved in Amnesia was great, the creative team producing the content were top notch, experienced developers, great creativity, knowledge, and good communicators. There was an excellent team feeling, even though everyone was working remotely in various places and our ‘office space’ was a constantly open chat box in Skype. This worked surprisingly well, mainly because the team engaged with it, constantly chatting about relevant topics, posting when making updates or taking a lock on source assets, making suggestions, spotting when the scale was completely out on a section of the game, etc. Good times. This period really reminded me of when I was full-time in industry, and the achievement of completing A Machine for Pigs and have it released, further pushed my desire to get back to working on projects more representative of the ‘full’ projects of my past, and move on from smaller/quicker mobile focussed products.

Amnesia was followed by Rapture, and again it was a feeling of returning to the familiar, being involved in discussions for the early prototype of the game, pitching such to Sony and helping to secure the engine technology. This felt like an important step for Dan and The Chinese Room, it was the step to becoming a ‘real developer’, with real money, real timing, for a real platform holder. With these real opportunities came the logical progression towards The Chinese Room becoming a real studio, so with that they withdrew from overlaps with the University of Portsmouth (my full-time job) to focus on the demands of a real full production schedule. I found this disappointing, given the investment that several of us had made to bringing the company to this stage, but understood from my own experiences that this was part of a studio ‘growing up’. I decided I would invest this disappointment into my own project, and push that to a higher standard, introducing more story, more themes, more quality, to emulate something of at least Amnesia levels of quality, but within the constraints of Unity which I believe had been updated to version 4 around this time, yes with much letter landscape and rendering performance in general.

In the space of around 12-18 months, my original easy to implement 3d puzzle themed AI baddie game, had shifted form an iPhone game, to a 3D story/AI driven horror adventure, based in a game engine that could barely manage First Person games, but wasn’t really designed for it.

My initial expanded story draft for the game had around 11-12 separate maps, each with a specific theme, that told a part of the journey the player was to go through. Early prototypes of levels ranged from 2km x 2km to 8km x 8km in size, I implemented around 5 of these roughly in Unity, shifting from map to map as my mood took me, to maintain my interest. Over time, and being involved in the map design for Rapture, it slowly became clear that such a massive area is an epic pain, both from the point of view of implementing and filling such, and also from the point of view of getting a player around the spaces quickly enough for it to be interesting. Add on to that the sheer number of assets needed to feed so many maps, wow, this was going to take a long time to implement. The original idea to implement so many maps seemed reasonable at the time, I was going to carry vegetation, assets and textures across maps, sharing themes in batches of levels, so there would be a good chance to re-use content, but each map would certainly need a good amount of unique content to help with themes and puzzles. Eventually I decided to scale things back, and removed levels that were clearly going to be duplicates, this brought the total down to 8 maps.

Time passes, Epic Games released the first public version of Unreal Engine 4, with full source code access. This is significant for me, as alongside everything else, I have been maintaining my (3rd) full 3d game engine technology, complete with deferred renderer etc (the works). The release of the UE4 source code, let me guilt-free step away from my game engine. My engine is still there, hosted on a private GitHub repo, just in case, but the freedom of not having to maintain technology, as well as trying to implement content for a game (hence my motivation for using Unity in the first place) was a significant release. The day UE4 was available for download was the day I dumped all my (not insignificant) investment in Unity and moved my project over to ‘a proper engine’.

So, the goalposts had moved again. With UE4 comes expectations of higher production quality. With Unity, even version 4, there was an acceptance from developers and the public, that products would have a certain ‘indie’ look to them, so visually functional but likely lacking in advanced technologies and polish. So, there are and were great Unity games, that played really well, but… visually weren’t at the edge of what was possible, even for the time.

Most of my art assets didn’t look great in UE4. Vegetation, trees especially, looked far too low poly, having looked acceptable in Unity. Speedtree came to save the day a couple of months later, but that was more time and money, revisiting the vegetation for the game, and working around bugs and underperformance in UE4 during the earlier releases. CryEngine, the tech we had gone for with Rapture was famous for its amazing looking jungles trees/vegetation. I couldn’t shift engine again, and I knew from my time with the source code for CryEngine, it wasn’t the engine for me, UE4 looked much more like my own coding style, so I could get around it quickly and easily. I’d just have to wait and hope that Unreal would come to me, and eventually implement Open World rendering performance to match CryEngine, thankfully, eventually, it did – but there was worry for well over a year.

With the increased complexity for feeding UE4, the increase in model quality, the increase in well everything quality, some further scaling back was needed. I had brought over 7 levels from Unity, a starting location to set the story (a map for this purpose), a typical level (which I’d made the most progress on in Unity), a maze themed level (with which I wanted to re-create the need to draw your own maps for games like back in the ZX Spectrum days), a classic horror themed location (because I had ideas for some effects), a slightly urban area (because I liked the idea of the buildings and the change in challenge), a huge map (intended to revisit the games themes and gameplay elements one last time) and a finale map (with surprise ending).

The finale map worked out really well, it was implemented in UE4 pretty quickly, based around the ideas I’d had for the Unity version, the main problem I had was with Speedtree Pine trees taking considerably longer to render than my deciduous trees did, but I managed to hack around a balance of tree types that worked. There is still a little placeholder art in there, but this was the first content I’d implemented in UE4 that set a high standard and showed the potential for the other levels. I then focussed on the starting map, and completely failed to make it sit well with the game and look, the lighting was just wrong for UE4, it felt tacked on to the story, so after wasting a month or so trying to make it work, I dropped the first level and repurposed an area of the second map to play the same role. This worked much better, and it was a relief to move on and to drop yet another level from production.

Then my focus moved on to filling the levels with detail, I decided not to focus on the code side of things for a while, because I’d tested the basic premise of the game logic worked in Untiy, and it was better than expected even with basic art assets, so I felt that focussing in ‘artist mode’ for a while would enable efficiently when producing content, and reduce the number of plates to keep spinning. For a while I jumped from map to map, implementing content as my mood and any spare time allowed. While progress was being made, it didn’t feel like it, because no one map seemed to be getting any closer to finished. I decided to focus on one map, and to speed things up, I started setting students at the university tasks to prepare assets for the game, so I could focus my time on areas that needed implementing. This would have been a great idea, if the students could have been relied on to finish what they started, finish such on time, or even to a quality or technical specification that was usable in a shipping game. I realised this was my fault, not theirs, I’d expected too much from them at a time when they were still working out what would be expected of them in the ‘real world’. So future tasks would be smaller, more specific parts of the asset creation process that could be managed by final year students, so some occasional success was possible, especially focussed around character design (thanks @LeeAnnPicknett).

With UE4 came a solid implementation of Physically Based Rendering, so all the texture and material assets needed to be also be revisited, initially this was a case of kludging the Unity prepared content into Unreal, before finally experimenting with the PBR production tools available, I invested in both nDO/dDO and Substance Indie packages (Substance was a lucky grab via a Steam sale, a bargain at the time). With Substance eventually winning the battle for my limited time and becoming, at least until they increased the cost of ownership, my suite of choice and my recommendation to others (students) to use. The introduction of substances had a bigger impact on the production pipeline of 3D assets than I’d anticipated. At first substances, in their texture form, were used to replace the older pipeline assets from Unity, so just replacing one batch of textures for another. But with the increasing visual fidelity of the PBR assets came a shift in which elements of a model might be included in geometry and which might be represented within the material itself. The material (substance) started to be more important than the overall geometry. So, we had shifted from a model taking the time and you would apply an appropriate texture at the end to, the material had to look realistic, and you then needed to model around that. ‘Anyone could model’, but it was really critical to have good PBR materials to apply to the model, to sell the reality and believability of the 3D assets in game.

I started to realise, if I’d stayed in Unity 4, the game likely would have been finished and shipped a couple of years ago. The visual fidelity would have been lower, but the community was trained to expect that from Unity at the time. The game idea and play would likely have been very similar to how it is now in UE4. It probably wouldn’t make a major difference to sales either. The original intention had been to ship a quick turnaround 3D game that might stand out from 2D games on mobile devices. The hope had been the game might attract enough interest, due to being more ambitious than most for the time, maybe get noticed by Apple, main paged, and possibly generate enough income so I could pay for an ongoing contract artist, so I could focus on my day job, and do essential development in my own time, dropping provided assets into future project ideas, saving myself a bucket load of time and getting products out quickly.

Should I continue? I understand investment, and I’ve invested a lot in this game, even knowing that the window for success likely passed a good time ago, my investment into the project to date makes it necessary to continue. I’m a firm believer that the difference between a creator and a wannabe-creator is actually finishing stuff, for better or for worse. While I could walk away from my own game engine, thanks for the open model of development for UE4, I can’t do the same for my own game.

I have ‘rested’ the game a number of times over the past 2-3 years, stepping away for a couple of months at a time, mainly during especially busy periods at work where I’m too tired at the end of the day to think of doing any extra work at home. Each time I return to the game with fresh eyes, I’m pleased and impressed with what I’ve done. Somewhat surprised that given for most of my games industry career I was a lead programmer/producer/technical director/M.D. and never the artist (apart from the very early ZX Spectrum games), I have done well with the visual implementation of the game so far. UE4 expects to be fed properly, with good quality assets, so I’m pleased I’ve been flexible enough to adapt to the challenge.

I am trying to see this as a sort of novelist approach to games development, like a writer sat alone with his typewriter creating a story, I’ve been doing the same with a game engine.

The typewriter approach might have been quicker.

Leave a Reply

Your email address will not be published.