You're late. They'll be waiting. You should leave; they'll be expecting you at the docks.
After three years Forward March is finally available online at itch.io for download.
Some of the visuals have been overhauled; mostly the lighting and sky, plus some bug fixes and usability tweaks. Importantly, it's major successes and failings are all still intact for your playing pleasure.
I'm pretty pleased with the result even though working on it was a brief struggle. Revisiting an awfully messy old project is one thing, trying to work with it is another. But done is done!
If you have any thoughts or feedback, I'm all ears!
Recently I've been collaborating with game dev Ben Wallis and fellow GEElab Phd guy Will Owen on a game design centered podcast and thought experiment, Playtest This, which went up on iTunes today.
In the first episode we talk about how we keep up with playing palette of games; mainstream, to experimental and outright broken, and the benefits and difficulties of staying in the know.
It's early days, we're planning to get another episode out soon, and keep it rolling into the future.
In November last year I presented at Macquarie University’s Games, Ethics and War workshop, alongside a diverse assortment of (excellent) speakers.
My talk ‘Warfare in the Uncanny Valley' went up on YouTube recently alongside all the other talks.
I discuss the representation of combat in Bohemia Interactive’s ‘mil-sim’ game Arma 3, it’s pros and cons, and how designers may better alleviate problematic elements, referring to some examples from film and games.
The workshop itself was excellent too, many of the talks were fascinating (seriously, check these out!).
Spec Ops: The Line’s (a game that I have a real soft spot for) design lead Cory Davis’ talk about crafting games as a ‘Vehicle for an Existential Conversation' is definitely worth a watch, especially for those interested videogames with the guts to simulatenously embrace, smear and challenge institutionalised tropes and themes.
It's been a bit of a dream of mine to visit the big ol Game Developer Conference in San Francisco since I was in my teens. Amazingly enough this year is my fortunate year, having been recently awarded a GDC 2015 Assist!
Thanks to the Game Developers Association Australia I'll be heading over to GDC 2015 in March alongside a bunch of other developers and friends who are also successful recipients, which is almost as exciting as the conference itself.
It's hard to understate how absolutely stoked I am to be going, and I can't wait to dive over the Pacific into the mess with everyone else.
I was interviewed a while back for long-running Australian games magazine, Hyper, as part of an education themed issue. Low and behold that interview has appeared in Hyper issue 255, alongside a variety of (great!) Australian game academics.
When I was young I'd frequently read Hyper and their sister magazine PC Powerplay. They both had a real flair to their writing and game coverage, making both a highlight of each month. I have enough nostalgia to have kept a ton of back-issues, including a monolithic stack of PC Powerplay magazines dating back to the mid 90s. Each issue is a little time capsule into my childhood and teens, and fascinating little windows into very specific times in games. And they still read well too.
With all that in mind it's super humbling to have my mug in one of these very magazines. Much thanks to the Hyper folks and James O'Connor for getting in contact!
Next Monday (24th) Macquarie University is hosting a workshop centred around Ethics and War in games. There's an excellent line up of speakers from various fields: game studies, Red Cross, military ethics, and game developers, notably the Spec Ops: The Line, and This War of Mine design leads.
I'll be flying over for the day and presenting 'Warfare in the Uncanny Valley', a talk discussing Arma 3's depiction of combat:
Since 2001 Bohemia Interactive has developed military themed games atypical to the mainstream. Their most recent title, Arma 3, continues this trend. It represents an all-encompassing philosophy to depict a realistic combat experience.
The high fidelity in both gameplay and environment design, is present from weapons to the flora and fauna of the Greek isles. Yet with increases in complexity and fidelity come complications. For instance, the game sanitises in-game human toll. This causes a disconnect between the reality of warfare and simulation.
If we are to maintain our suspension of disbelief, how may developers better address this? How might we make simulated warfare more believable?
Being a long time fan of Bohemia Interactive's games (Flashpoint and Arma in particular) it's a topic I'm looking forward to discussing!
Melbourne Knowledge Week 2014: Exploring the Potentials of Virtual Reality
This Wednesday, 12pm at the RMIT Design Hub I'll be presenting alongside five other researchers in the Exploring the Potentials of Virtual Reality workshop, as part of Melbourne Knowledge Week 2014.
It'll be a cool session that has been in the works for a few months. We'll be covering a range of VR related subjects, from physically walking around virtual spaces using body tracking, virtual avatars, architectural visualisation and of course, game development. I'll be covering the later in 'How (Not) to Design a VR Game' discussing Deep Rift's development and working with the Oculus Rift.
A selection of Oculus prototype demos will also be on display. Currently I'm working on a bus-surfing minigame with William Owen, built Unity using RMIT Senior Lecturer Stefan Greuter's Space Walk technology. It's the right kind of crowd pleasing silly fun and solid tech demo.
Melbourne might in it's own little continental corner of the world's games industry, art and culture scenes, but it sure knows how to make it's own waves. It's tight-knight headstrong industry, indie, creative arts and criticism scenes all tend to get a visible amount of crossover; noteably in events like Freeplay, Parallels, (wonderfully run and managed) IGDA chapter events and Games Connect Asia Pacific; the local industry conference here.
I'm still baffled that I hadn't ever attended a GCAP conference before, especially when money wasn't so tight in the past, unlike now, post GDCE. However I was fortunate enough this year to receive a GCAP Assist award-thing, providing me and some lucky others with a ticket to GCAP 2014. A special thanks to the GDAA and Epic Games for sponsoring us!
You can bet that anything story or design related I'm eyeing intensely, and the speaker line up seems ace. Better yet, being able to meet a bunch of local game devs in person and put some faces to those Twitter handles.
After a month gallivanting around Europe I'm back in Australia, settling back into PhD mode. I left with GDC Europe and Gamescom in my sights and what unfolded exceeded my expectations. It's easy to go a bit stir-crazy working in a field that's small and geographically isolated, especially when so much that happens is largely overseas. Thankfully the trip was a welcome breath of fresh air, and exactly what I needed for helping pull the reigns on what often feels like work that wildly veers from side to side.
The leg of GDC Europe and Gamescom experiences have all been distilled in an article for the IGDA on their Scholars page. It's a bit of a mammoth, but I couldn't have written about it any other way.
I was very accustomed to UDK a years ago, off the backs of many years of modding Unreal Tournament games. However since picking up Unity 3D I never returned, and UDK with it's fairly rough tools and idiosyncrasies eventually fell out of favor.
After building Deep Rift in Unity, artist, friend and fellow GEElab PhD guy Will Owen insisted on moving to an engine with art tools 'better than Unity's hot mess'. Over the month what started as Will tinkering with UE4's art tools eventually became an attempt to convince me to also jump on Epic's ship.
So after Will's tireless pitching and properly seeing the gross improvements since UDK and general ease-of-use, I can safely say that our Oculus Rift submersible stealth / horror game Deep Rift is making the transition to the engine.
Deep Right has a simple enough design to translate and using Blueprint, the visual scripting replacement for UDK's janky Kismet. Impressively Will has already put together a steerable submarine prototype, made out of prefab tables, with working ballast controls and all.
I might document development as it goes (if I have the time) and I'm sure Will shall go into detail once his site is up and running. In the meantime the first results are promising and it's interesting to see Epic proving to be real contender to Unity.
And I have to admit, it's exciting to be using Unreal again.
Melbourne Knowledge Week 2014: Exploring The Potentials of Virtual Reality
As part of Melbourne's recurring Knowledge Week later this year I'll be running a presentation and hands-on demonstration with fellow RMIT peeps-&-grads William Owen, Dr. Johnathan Duckworth, Dr. Stefan Greuter and more.
We're discussing practical application of Virtual Reality, and more-or-less providing an overview for working with the tech, spanning a brief history and introduction to the field (theory, tech, research and commercial use); design considerations, 3D engines and development practices; architectural visualization; and the potential for serious games and alternative uses.
Details should go up on the Melbourne Knowledge Week website publicly soon enough, which I'll follow up. For anyone new to the field and interested in getting into Virtual Reality and the Oculus Rift space it'll be worth a look
As a preview check out Stefan Greuter's article about building a VR system that accommodates physical movement. It's a interesting read and having used the kit there's something to be said for physically moving around a virtual space. Even if the latency isn't quite there yet it's a strong enough indication that we're one step closer to that Cyberpunk future every dork has been holding out for.
Recently I was fortunate enough to receive an IGDA Scholars award, giving me the opportunity to attend the Game Developers Conference Europe 2014 and Gamescom in Cologne, Germany in August.
I'm stoked! Between PhD work, writing and external projects it's absolutely refreshing to have some travel on my agenda, let alone the opportunity to meet a whole lot of new people. I attended Gamescom in 2011 and while it was a memorable experience, I was kicking myself that I didn't attend GDCE that year. So now I'm making amends.
I'll also be paying my German colleagues at GEElab Europe a visit while I'm over too, and I plan to cover a bit more ground. Berlin maybe? Aside from the impact on my bank account it's exciting times ahead.
Deep Rift Postmortem, Part 3: Level Creation, Crunch, Showtime
It was the final few days of development for Deep Rift.
The final core gameplay features were implemented, namely the monitors within the submersible's cockpit. Easily done, there were four, each a flat polygonal surface rendering external cameras to assigned materials. The effect worked well however the performance impact wasn't great, although it did enhance the core 'sneaking past sharks' gameplay. Separate monitors to look would emphasise the players situational awareness when using the rift in combination with the sonar effect.
With some moody effect grain filters added to interior monitors and the interior cockpit lighting nailed down, there was little time for much more development; level creation, art asset production, before the inevitable event demoing.
Level Creation Slammin'
With the fundamentals sorted a level was necessary to put them to test, crunched within what little time was left. I absolutely love level design; sketching it out, doing rough blocky mesh geometry, figuring out weird spatial designs and balancing levels, construction and adding art assets. Only I hadn't assembled a level for 6DOF gameplay before.
This was dumb. This was a mistake I had made before. Don't ever leave your level design and production to crunch time. Core features are one thing but having a well thought out environment that puts those features to proper use is another.
Thankfully I had pre-prepared, sketching out numerous layouts previously for fun. I had figured out a general level flow, making use of vertical and horizontal tunnels. Flat planes are boring, especially when you're in a 3D space and gameplay centres around situational awareness.
My design process was what I imagine Parallax figured out when they were designing Descent; 'there's no reason not mess around with the players sense of space'. I could write an entire section on level designing for 6DOF games, but the basic principle for my design can be found in many games
I'm no hotshot expert industry level designer, but I'm all for building your level around a central environmental piece and goal. Like the interconnected chambers between a literal central Blast Pit in Half-Life, the inwards spiral of The Silent Cartographer in Halo and the decapitated Lady Liberty on Liberty Island in Deus Ex; find an angle to guide and centralise to your architecture, so you have a core base in which to refine it around. Successful designs can give the level character and gameplay shine more than any pretty art asset can.
That's not to say art assets are needless at all though! And in this instance I was completely lacking them to replace the design-reference cube primitives. With the art-man-himself and co-creator Will overseas and unable to shoot over any more assets, I was in a pickle. At this point I couldn't care less how nice the game looked, but assets were vital for practical reasons; guiding markers, obstacles blocking line of sight, to steer around etc.
Scrounging for Art Assets
At this point I pretty much ruined the sort of clean project folder hierarchy I had going, dumping in Unity demo assets - notably the Angry Bots demo. It had industrial art assets and more importantly, rocks. Using these assets I quickly threw together a few prefabs to populate the level, with basic collision hitboxes.
The level architecture was coming together, tunnels interconnecting at central points and a variety of underwater rock formations and areas, populated differently with shark enemies. The array of free resources available is part of the beauty of Unity, I'm sure it has saved plenty of other developers like-so. However what was missing were a definitive exit point makers to the level, an ending, and a bit more character.
Contacting a indie-dev bro of mine, Jason, I asked if he could possibly throw together some art assets, models and textures. 'Whatever you think is cool' was my only guideline aside from mentioning that a giant 'mother submarine to steer into' as a final goal (the players escape) and game ending asset would be rad. Being an absolute top guy Jason was excited at the proposition of doing some 3D work let alone modelling a submarine, having worked overwhelmingly in 2D for the past year or so.
Friends are the best. Dev friends especially. It's always good to know some people to ask in crunch times like this, just be sure to shout them a beer, coffee or a Steam game afterwards.
Some ship wreckage assets and a giant, groovy looking boxy mother submarine like out of a 70s sci-fi were promptly sent my way. Once added the rushed game environment had a bit more aesthetic character to spruce up it's many rocks. More details like reeds or bubbles would have been ideal but time had run out, the following day was the first public demonstration for RMIT's O-week festivities.
Demo-Day
The first day of demoing Deep Rift was at RMIT University's Brunswick Campus outdoors in a tent on a typically hot March day. The second day would be RMIT's City Campus, and a few weeks later Deep Rift would be run at a charity event.
On the first day aside from the array of RMIT organisations on show at the campus there was little in the way of activities, with the game put in a central outdoor causeway -we had no flyers, banners or anything like that. I can deal with being rag-tag unprofessional but public setups like this are not something I'm used to, usually it's a link to a .zip file sent through an email. That's not to say I don't enjoy it.
With most of the game's bugs under control and it running stably, baked, packaged and running off an executable the demoing could begin. Ideally I would multitask between helping people play the game and edit a paper I had been writing, but it turns out the Rift's learning curve combined with 6DOF gameplay really requires a much more hands on approach.
And that was really fun.
Basically publicly demoing the Oculus Rift turns you into a theme park ride operator.
The Part Where People Actually Play It
On the first day Deep Rift demoed really well, about 30-40 people tried the game over the course of a couple of hours. While the Oculus Rift was the major draw and novelty it was surprising (for me) to see people enjoying the game, and playing it as it was originally intended. Players had to be briefed on the controls (and at times assisted), objective (navigate through caverns) and coyly hinted at about enemies / obstacles.
Everyone typically took things slowly. Slowly taking in the VR goggles and head tracking, that was enhanced by the slower pace of gameplay. This further feeded into observation and awareness behaviours that I originally sought to encourage. Sometimes players had to be reminded about head tracking but surprisingly many naturally adapted to it, checking the cockpit monitors and peering around the cockpit's bubble window.
Also surprising was how players actually found it tense and scary. Not terrifying but tense enough to elicit some yelps and jumps. As far as I was concerned the shark and it's animations were goofy, but for most players it was convincing enough. I'd attribute this not only to the animations and art but also design considerations like the fog, sonar and low line of sight; concepts working as intended. It's not often I see things click together like this, so having it happen there in real life, and people enjoying the game was pretty damn humbling.
Interestingly none of the problems were really surprising, most were predicted beforehand. The 6DOF movement combined with the Rift resulted in a steep learning curve for most players, the submersible's physics broke here and there, level navigation could be a bit confusing due to a lack of makers, and the UI was awful.
I'd observe each player, jotting down a few notes and casually asked players about their experience once done. While the first taking point was about how crazy the Rift was, the general consensus was that the game was engaging and fun, enough to justify replays for a few players. They varied from people with a casual interest in games, some who knew what the Rift was and others with no idea other than 'what's that weird thing, I want to see'.
Day two was at RMIT's city campus, and despite a particularly bad allocated location with far less foot traffic, it went as well as the previous day with higher attendee numbers (a shout out to Scott and Adelle for swinging by and giving it a go). Probably coming to about 40+ attendees, most were undergraduate students starting out and re-enrolling. Bad space allocation meant we were near a enrolment line, but this also meant there was a watching audience.
From my experience play testing for smaller games usually happens as development goes, sometimes involving co-workers, friends or people nearby give it a shot. While Deep Rift was given a place at an event, demoing with the general public in person was ideal. It was a great way to obtain a diverse set of feedback within a short time span, and quickly distil the game fundamentals to people completely unfamiliar with it, especially when grappling with the less explicit conventions of VR hardware and design. Being able to see how it translates right then and there between a variety of people and actually watch their behaviours in and out of game is more than idea. It's no Valve tier user testing, but it's the next best thing.
Winding Down and Final Demonstrations
Following the two days at RMIT we were approached by Uniting Care to demo Deep Rift at a youth charity event a few hours out of Melbourne. With Will arriving back from his stint in Europe it seemed like a good opportunity to do something nice, quickly polish the game up and see what another audience thought of it. This mainly involved replacing art assets, modifying the level design, and more-or-less polishing the entire thing.
Attendees were mainly of a young audience, mainly late primary and early-mid secondary school aged kids. Deep Rift was one of many attractions at the charity event; and it turns out it was a little bit of a hit. The spectacle of someone wearing the goggles and headphones attracted an audience, parents and their children each giving it a go and swapping the Rift and controls between each other (requiring liberal cleaning of the Rift's lenses).
Unfortunately in the last half-hour of the event the game began to continuously crash (I believe it's because of the submersibles physics, a by-product of my awful, awful hacked-together programming) and the control bindings ceased to work. We conceded and booted up Dreadalls, an great short horror game made for the Rift instead.
One little moment sticks out to me, a kid who must've been around eight tried Deep Rift, and came back to see Dreadhalls. After taking off the goggles he mentioned that he "liked the shark one more" and would "save up and buy it one day".
I'm not going to ever say our rickety thing is better than Dreadhalls but that moment right there for me justified this short development saga, and still has me grinning well after.
Deep Rift Postmortem, Part 2: Stupid Sharks, Mechanics, Mood and Blunders
At this stage of Deep Rift's development I had finally cobbled together a working submersible character controller, integrated the rift rig into Unity and a couple of 3D models imported. The later was wonderfully simple. Once the submersible controls were worked out, it was a simple task of bolting on a prefab Rift camera rig, from their default character controller, and fiddling with options.
With enemy a.i., a damage or health system, basic UI, menus, animations and underwater camera effects on the agenda -oh and a game level- there was still a lot to do, and the clock was counting down.
Everything Goes a Bit Crazy
This is where things started to become a bit problematic. Will had a travel dropped on him, a research trip to the GEElab's German half in Karlsruhe that had to be undertaken. This more or less cut his availability to pieces, resulting in some working from Germany on his end, sending assets to me. The travel also overlapped with d-day demoing at RMIT's O-week festivities for two days, on different campuses, so the onus more or less fell entirely on me. I was also writing a full paper, due for submission on the very same day, so everything felt like it had gone to hell very quickly.
So the challenge was on.
Because of the time constraints we decided enemies would consist of one variety of great white shark. Originally we had plans for sharks and another octopus alike / Lovecraftian thing, the former at the start of the level, the later towards the end, but even prior to shit hitting the fan it was probably too optimistic for production. Why were sharks in an undersea cavern? Who knows, context was more or less thrown out the window at this point.
Shark Making and Game Logic
I have a hard time calling the shark's behaviors that I wrote a.i., seeing as how hacked together it was. A medium sized spherical trigger was attached to the model, if the player hit the trigger the Shark model would rotate towards the player and move at a constant rate towards them. Another spherical trigger (larger) was attached; if the player managed to exit this trigger when the shark was alerted it would cease to chase the player, giving them an out if they alert the enemy. Basic stuff which worked well, avoiding the need for diving into raycasting and more complicated areas.
Issues were raised in pathfinding, and I didn't seem to be able to find a decent reference for pathing enemies in 3D space. On a 2D plane, sure, easy, in a void? No idea. For this reason behavior was limited to the shark turning and moving towards the player, regardless of line of sight or objects in the way - they would continue to travel at the player until they were either dead, or outside of the trigger, into walls, rubbing on edges you name it. In a 3D movement space however this actually worked out well - and we were planning to limit the players view distance with an underwater fog effect.
This was an instance of if you can mask it and no one can tell the difference, do it.
Sticking with the trigger theme a small forward facing trigger on the shark would be it's damage output; coming into contact with the submersible's hitbox would damage or kill the player. Like most videogames, instant death when you're not given a heads-up or awareness didn't lend itself for an enjoyable gameplay experience, especially for an audience wrapping it's head around sub controls and VR goggles. A basic health system was implemented for the player, and a damage output rate for the shark; if the player was within the trigger damage over time would enable.
There were some issues with the damage triggers being triggered by the shark player detection triggers, so once proper labeling had been added to the scripts everything worked fairly well, as rudimentary as it was. Sound effects were added to the sharks; a pinging effect was used, it's audible area extended outside of the shark's detectable range, rising in volume the closer the player got towards the shark (a hull hitting effect when damage was being dealt). Unity's basic audio tools were perfect for this, and this small design decision and audio file added that extra dynamic to gameplay that we were looking for. Sound and vision were your main methods of survival, matching up very well with the sensory deprivation in a sub theme we were going for, our gimmick angle and the VR experience.
At this point we actually had a game coming together, with little time remaining.
How not to do a User Interface with the Oculus Rift
In a nutshell, the players life and damage being dealt to them by sharks needed to be more accurately telegraphed than audio cues and visuals. Doing basic programmer art I put together a rudimentary health bar attached to the ingame cameras GUI.
This was dumb.
Traditional GUIs do not work with the Rift's dual lenses, crossing over and blurring. I completely forgot that every other Rift game and demo uses an actual physical interface within the game space, not a traditional GUI. I won't be making the same mistake again, but either way, it worked and was pushed to the side for more pressing issues.
Don't do what I did.
Camera Effects
Making the game feel like it was underwater in the deep sea was imperative; sound, colouring, fog and particle effects were decided as the best way to convey it. Unfortunately with Will, the number 1 art dude on the project flying away at this point only so much could be done.
A lot of this was a blur of development, a lot of fiddling with options and little remembered.
What I can recall: Doing any sort of camera effects with the Rift camera setup in Unity is an absolute bastard. Effects don't line up correctly and overlap because of the application to dual lenses. A lot of tweaking is required, mostly involving messing around with positional offsets. I think.
I highly recommend doing the Rift exclusive stuff first if you're deciding to make a game for the technology. It'll save a lot of pain and frustration once you've worked out the parts that actually work with the software meets technology limitations, compared to parts of production that translate to any other game.
Regardless everything put particle effects were implemented for now (those were added at a later date) and the game actually looked convincingly enough like an underwater setting. With the addition of shark enemies and a controllable sub there was an actual playable and novel game here.
Low and behold it was actually kind of fun to crawl about keeping an ear and eye out for sharks.
Unfortunately up until this point an actual level hadn't been developed and some of the sub's features still hadn't been added. With a few days to go development would be down to the wire.
Continued in Part 3, rushing level design and construction, decent use of render-to-texture and d-day, demoing for the public and playtesting.
Deep Rift Postmortem, Part 1: A Foray into Virtual Reality
Earlier this year my co-researcher Will and I were trying to weasel our way into getting an Oculus Rift. What started as a joke eventually lead of the creation of a VR game, Deep Rift, built in a crunch time for public demonstration.
It was our first attempt at building something for VR, Will being the artist and I being design-programmer. What unfolded, our experiences and what we learned became an interesting little saga in the what to and what not to dos when designing, development and demoing VR games.
So you want an Oculus Rift? You'd like to make an Oculus Rift game?
Here's how we did it:
Then and now Virtual Reality is a bit of a hot thing, there's so many articles floating around and games media singing it's praises that it's hard not be to be interested in the tech, it's implications, and the promise of playing a growing catalogue of weird experimental games like Dumpy and pre-existing games adding support, like comfy-simulator Euro Truck 2.
However we didn't have the appropriate funding for a Rift at the time, so in our single-mindedness we looked at our (lack of) options and settled with pitching a game to RMIT University's events organization. As part of the first week of Uni festivities aimed at new students, many fresh out of highschool, we proposed an idea we had been throwing around for a VR game.
The Pitch
A short horror themed game set underwater in a submersible - think Amnesia meets Descent.We both like vehicle based games and share extremely fond memories of shooting mechs in mechs in Mechwarrior 2, and enjoyed the more clear-cut mechanical design of recent horror games, so the concept seemed like an inherently interesting one to take a stab at and develop. The design was relatively simple - the player pilots a sub through an undersea cavern network. There are night vision monitors in the sub and sonar. There are monsters in the cavern. The player sneaks around monsters using the sonar and monitors or quickly rushes through the caverns (which expand and shrink), towards the escape. Pretty feasible.
It also pretty clear that people watching other people getting spooked while wearing the Rift on Youtube was a popular thing, so we figured the game would make a fun public spectacle as much as brief VR experience for the general student audience.
The pitch was a success and the organizers were pretty excited, netting some funding for equipment and resources. Now we actually had to make the thing.
Early Production
Unity was settled on, it's strong native support in the Pro version for the Rift made it a no-brainer next to UDK's more flakey support, and my own past experience with the engine and editor made things a bit easier, though Will was pining for making the game in UDK because of Unity's rough art tools. A bit too much time was spent messing around with both engines at this stage, trying to work out which best suited the practical realities and aesthetic qualities of the game, but it was a good way of needing things out for the future. Also problematic were the other tasks at hand, writing, research, classes and other paid projects, so some juggling and time management was in order; usually one or two days a week spent on the game, increasing towards the deadline.
Basically Unity is great for this kind of thing.
The abundance of Rift games using Unity also provided an array of cool references for design and production techniques. Plenty of demos and games were sampled to come to terms with what approaches should be taken - the vehicle based perspective and controls were one byproduct. The natural head tracking motions using the rift didn't quite work in tandem with mouse and keyboard controls in first person character based games. The rift works with your natural body movements while you're abstracting movement within the digital space, and in many instances rotation, to keypresses or joysticks. This isn't something that bothers me, or Will - we're both fairly used to TrackIR and game controls, but for folks who don't often play games who we observed, there was some difficulty actually abstracting what controls do what when interfacing with the game.
For this reason we settled on a seated cockpit position inside the submersible, using gamepad thumbstick controls; there was logical continuity between physical the virtual spaces. The one downside here was our use of six degrees of freedom (6DOF), allowing players to 'fly' or swim about a 3D space in any direction. Just like Decent in the mid 90s this concept confuses the hell out of people still, part enhancing the VR experience, particularly the head tracking, and part confusing and nauseating players. For a short game it was a good enough novelty for us to thumbs up and proceed with production.
Demoing pre-existing games and having a variety of people play (and observe) was a massive help in the early stages of production. It's early days in game development for this current tech, so obtaining feedback around it, pre-player testing your own work is highly recommended.
Early prototyping was spent mainly around nailing the submarine character controller and coming to terms with the Rift's idiosyncrasies. For Will it was working out the art tools and pipeline in Unity. Let it be known that I'm still a pretty bad programmer, and this was an extremely tricky part of development. Normally I'd concede and use the visual scripting plugin PlayMaker, but in this instance I kept at building the submersible from the ground up. This was both the hardest and the most fulfilling parts of the project for me, however it resulted in less level and enemy production time.
Another downside is that the submersible controller was rough and extremely buggy, prone to physics freakouts and weird logic. Many of the references I was using (mostly spacefighters) had their own issues that I incorporated into my own, leading to a horrible clusterfuck of code. But it worked and still works; eventually I'll rewrite everything bury those scripts in a folder of shame.
At this stage models were starting to funnel their way from Will into the game, giving some character the cubes and unlit blue void. A large shark model and initial submersible model were implemented; The shark big and goofy, the sub featuring an exterior body and more detailed visible interior with flat monitors. Scaling was an issue here. The Rift's dual lenses and rig setup within Unity results in a weird field of view, which only makes sense when you're actually looking through the goggles.
It was super important to test the balance of object scaling in-game using the rift before proceeding with more art assets and level sculpting; this way the parameters surrounding the Rift's odd perspective could be nailed down saving future problems. Also highly recommended.
Continued in Part 2: Shark behavior, UI mistakes, level sculpting and ohshitit'scrunchtime.
This month I was approached by the UK/Australia based news, opinion and analysis site The Conversation, to coincide with GDC 2014. It's a site for various professionals and academics to cover relevant topics for the general public. I've enjoyed articles there in the past and their standard of writing is something that I can get behind -so I was pretty stoked to be given this opportunity.
Indie videogames are taking it to the next level of story design
Story design considers game mechanics an expressive part of a game’s story. JD Hancock
This week’s Game Developers Choice Awards at the Game Developers Conference (GDC) in San Francisco saw some of the usual big hitters win, but also, intriguingly, smaller independents such as puzzle game Papers, Please (2013), which won the Innovation Award and Best Downloadable Game, revealing a new trend in videogame storytelling.
So, what’s the trend?
The rest of the article can be read in the flesh at The Conversation.
The article is about narrative design in games built on some papers I had on ice (which might be posted at a later date), and my previous writing. This time however I decided to use indie games as my angle which fit what the flavour the editors were looking for. It was also and was a good way to distil what this designing stories for games thing is all about. I think it came together pretty well, though I wish I rolled with more specific 'narrative design' definition instead of 'story design'. Oh well!
And the 'next level' title wasn't my fault. I swear.Though I have nothing against their cover image choice.
