I can remember 8 years ago when Dreamfall first came out and my collective group of friends all talking about playing it. This was just when my love of cinematic styled games was starting to bloom with titles like Fahrenheit only just having graced the shelves. However I was told with no uncertainty that if I was going to play Dreamfall I had to play its predecessor, The Longest Journey, before I could dive into it. Considering that game is some 40 hours long (or more, depending on how long you got stuck on the rubber duck puzzle) it would be no small investment but suffice to say I’m glad I did. After a wildly successful Kickstarter campaign Red Thread Games is finally continuing the story of Zoe Castillo and her journey to save two worlds from the impending darkness.
Betrayed by a mother she only just found out was still alive Zoe has been trapped in the story time, a place which exists between the twin worlds of Stark and Arcadia. Her body lies motionless in the real world, hooked up to a machine that ensures she stays alive but makes no attempt to bring her back. She has found purpose in this world however, saving those who’ve become trapped in their dreams by the Dream Machines by guiding them back to the light and warning them of their danger. This is not what was intended for her however as the darkness that threatens to engulf both worlds still spreads even in her absence. It is time for Zoe to make a return to the real world and to return to her journey.
Dreamfall Chapters looks decidedly previous gen in terms of graphics as it lacks much of the graphical fidelity of its current gen brethren. Primarily this is a function of its use of Unity and cross-platform ambitions which limit the amount of eye candy you can use. However that being said it’s far from an ugly game, with lovely expansive environments that are just brimming with details. It’s definitely best played with an expansive view (both figuratively and literally) as the bigger picture is so much more than the sum of its constituent parts.
Dreamfall Chapters takes inspiration from the Telltale style of story based games, stripping away all but the essential mechanics and instead placing a heavy focus on the story and player agency. You’ll be following the stories of 2 individuals, the first being Zoe Castillo, the main protagonist from the first Dreamfall game and Kian Alvane, another one of the main characters from the previous title. Dreamfall Chapters retains its adventure game roots, giving you all manner of puzzles to solve in order to progress the story, however it now also includes choices, both major and minor, that will affect the outcome of story. It’s a formula that’s worked well for Telltale for the past and to their credit Red Thread Games have managed to take the essence of it and make it their own.
In terms of game play this first instalment (Dreamfall Chapters is now an episodic game) feels a lot like an extended tutorial coupled with a reintroduction to all the characters, worlds and stories that exist within them. A lot of the mechanics you’ll encounter, like shining a light on things to reveal something that can’t be seen otherwise, are mostly things you’ll only encounter once in the game but are obviously being set up for use again later down the track. You’ll be able to pick up the vast majority of them without too much hassle especially if you’re a long time adventure game player. There are a few puzzles which feel like they’re an homage to the ridiculous puzzles of yore (the pillow on a broom is one example of this) however for the most part you likely won’t find yourself stuck at one point for an inordinate amount of time.
The dialogue choice system is probably Dreamfall Chapter’s stand out feature as it’s leaps and bounds above what’s in most other story-first games. Instead of being given a bunch of options to choose from with just a small blurb to go on you’re instead treated to the inner monologue of the character as if they’re making that decision. This has two benefits, the first being that you’ll always be sure that the decision you make is in line with what you choose. Secondly you can get a feel for how Zoe thinks her decision will pan out which can sometimes change your mind on how you want a particular situation to play out. On the flip side however this does require you to go through the options fully before making a decision as the dialogue that follows is usually brief and provides no further insight that what can be gleaned from listening to their musings prior.
Mechanically the game is pretty much bang on with performance being great and not a crash to be seen throughout my playtime. However the look to select system feels a little wonky, often requiring you to shift your character and camera around multiple times in order to be able to interact with something. This can be rather frustrating when you notice something pop up (a little eye indicates you can interact with something) only to have it disappear the second you stop to try and click on it. It’s not something that will prevent you from progressing within Dreamfall Chapters, but it does feel like it happens more than it should.
Dreamfall Chapters does a good job of setting up the world that the rest of the game will take place in, reintroducing many of the characters from the previous games and filling in their stories of the past year that Zoe’s been out of action. Whilst the majority of the story is exposed to you directly there’s a fair amount of detail crammed into Zoe’s journal which can be a little bit of a chore to read through. Given the time between the previous game and this one though it almost feels like it’d be worthwhile playing through it again as some of the larger story elements rely heavily on the back story that was built back then. Indeed Dreamfall Chapters isn’t designed for those who are just becoming familiar with the franchise as it leans heavily on what came before it.
In terms of the story of this instalment it’s clear that the primary focus was on setting up the initial world that the following chapters will build upon. Considering the wealth of background that’s available in 2 other games they can somewhat get a free pass for not developing the characters much however if you’re looking for the story of Dreamfall Chapters to go places quickly you’ll unfortunately be disappointed. Don’t get me wrong though, there’s a lot to love in here, you’re just not going to be cemented to your seat from the second you click play.
Dreamfall Chapters fills a hole that’s long been in many gamer’s hearts, continuing the story of Zoe Castillo that felt like it was cut abruptly short at the end of the previous game. It might not have next generation graphics or play as smoothly as some other adventurers other there however it makes up for it with one of the best dialogue systems I have seen in recent times. It will be interesting to see how the player choices pan out in the greater story as they’re making a big deal about player agency and I hopeful that they will be able to deliver on it. Dreamfall Chapters really is only for fans of the series but should your interest be piqued I would heartily recommend making the investment to play through its predecessors.
Dreamfall Chapters is available on PC right now for $29.99. Total play time was 3 hours with 86% of the achievements unlocked. The writer was a backer of the Dreamfall Chapters Kickstarter at the $500 level.
I’m no stranger to game development, having dabbled in it when I was at University. It was by far my favourite course as whilst I had a decent amount of programming knowledge translating that into creating something playable seemed like a monumental step that required a whole lot of knowledge I simply did not have. This was long before the time when tools like Unity or GameMaker were considered viable and our lecturer made everything easy for us by providing a simple framework on top of DirectX, allowing us to create simple 2D games without having to learn the notoriously complicated API. Since then I’ve tried my hand at Unity several times over and whilst it seems like a programmer’s dream there’s always one place I come unstuck on: the art.
This isn’t exactly an unknown issue to me, all my university projects used sprites that were pilfered from various free game resource sites and anything extra was little more than primitive 3D objects whipped up in 3D Studio Max. For my current project however I had the bright idea to try and generate some terrain using one of those fancy bits of software that seem to make good looking landscapes without too much hassle. After wandering through a sea of options I found Bryce seemed to be the one to go for and, better yet, it had the ability to export all the mesh so I could import it directly into Unity without too many hassles. For the $20 asking price I figured it’d be worth it to get me going and hey, should I want to go full procedural down the line it’d be a good introduction into the things I’d need to consider.
Oh how naive I was back then…
Whilst Bryce is everything it claims to be (and the tutorials on using it are really quite good) I just couldn’t seem to get it to create the type of scenery I had in my head. This is entirely a user based problem, one that I’ve suffered with for a long time where the interconnects between my brain and the tools I’m using to create just don’t seem to be able to gel well enough to produce the results I’m looking for. Whilst I was able to generate a decent looking mesh and import it into Unity it was nothing like I wanted it to be and, after sinking a couple hours into it, I decided that it was best left to one side lest I uninstall everything in frustration.
Realistically though the problem was one of expectations where the disjoint between my abilities with a program I had never used before and my expectations of what I’d produce were completely out of alignment. After mulling it over for the past couple days I’ve come to realise that I had set the bar way too high for what I wanted to create and indeed creating such things at this stage of development is actually a distraction from the larger goals I’m trying to achieve. I’ve since settled on just making do with a flat plane for now (as that’s all I’ll really need for the foreseeable future) or, should I really want to put something pretty in there, I’ll just lift a 3D model from a game that’s close enough so I’ve got something to work with.
You’d think after churning through project after project I would’ve become adept at recognising when I was pursuing something that was antithetical to making actual progress but it seems even after so many years I still find myself making things far more difficult than they need to be. What I really need to do is focus on the parts where I can make good progress and, should I make enough in those areas, then look towards doing the parts that are outside my area of expertise. Of course the best solution would be to partner with a 3D artist, but I’d rather wait until I’ve got something substantial working before I try and sell someone else on my idea.
That is unless you’re one and you’ve got nothing better to do with your time
Cross platform development is one of those things that I’ve seen done dozens of times before but rarely do I see anyone get it right. I understand the allure of doing so, heck my most creative forms of procrastination came from experimenting with these ideas, but the fact remains that more often than not they’re going to be a total waste of your time. I do have one exception to this rule however and that comes in the form of the cross-platform game engine Unity. Where other libraries promise compatibility and a wide range of functions Unity actually delivers on these with little compromise. Couple that with their ridiculously good pricing model and awesome dev environment and it’s hard to fault the product. Indeed all the shortcomings I found were, as far as I could tell, limitations of my programming expertise.
For games developers Unity offers the chance to have one code base for all platforms with only minor tweaking required once you want to deploy the project to your chosen platform. This is great because initially you can focus on one platform and then once you’ve verified your product there it doesn’t take much to port it to the new platform. It’s no surprise then that you’ll find many Unity based games in both the Apple and Android app stores. Figuring that Unity was going for all round platform domination I thought it was only a matter of time before I saw that the library would support Windows Phone 7, even though it’s still in its nascent stages.
As it turns out however that won’t be happening:
The Unity engine does not support Windows Phone 7 because of restrictions placed on Microsoft’s mobile, the CEO of Unity Technologies has said.
“But we’re looking at Windows Phone 8 and hopefully it will be easier to work on that system,” he said.
In an interview with Develop, to be published soon, Helgason explained Windows Phone 7 “is a relatively closed system so you can’t run native content, which means we can’t really support it”.
The “closed” nature that David Helgason (CEO of Unity) is referring to is the fact that if you want to put a game on the Windows Phone 7 platform you need to have coded it in either Silverlight or Microsoft’s XNA framework. Unity then approached Microsoft to see if they could get an exemption from this rule (as well as access to some private APIs which would be required for their libraries to work) however Microsoft turned them down. This means that Unity and all the games built on top of it are banned from being released on this platform, save for a full rewrite of the code. In response Unity has turned their sites towards Windows 8 which will be a lot more friendly for them thanks to the WinRT framework.
This feels like a pretty big misstep from Microsoft. Windows Phone 7 hasn’t been gaining any momentum and it’s overall smart phone market share (that includes Windows Mobile devices) has been taking quite the battering dropping to a low of 1.6%. Whilst I won’t go as far to say that Unity would be its saving grace it definitely wouldn’t hurt to have that available as an option for games developers looking to develop for the Windows Phone 7 platform. Indeed since Unity supports coding in C# I’d hazard a guess that there would be quite a few who’d be willing to give it a shot just because it would be easy for them to learn. Heck I know I did.
In reality Windows Phone 7 has a lot of other hurdle to overcome before it can be considered a serious competitor in the market but Microsoft can’t afford to throw away any potential advantage it can get. Not working with Unity only serves to damage the Windows Phone 7 platform as it has demonstrated success on every platform it’s available on. Unity developers then may have to wait for Windows 8 and the corresponding Windows Phone release before they can think about coming across onto Microsoft’s platform but I feel that may be too far off, and the damage has already been done.
I can remember sitting in one of my university lectures a long time ago being taught about development philosophies. It was all pretty standard stuff, we were walked through the “traditional” methods of development (basically the once through, waterfall technique) and then brought up to speed on the more modern iterative approaches. However one little soundbite always stuck out in my head and that was when the lecturer asked us who pays for rework when a product doesn’t fit a customer’s expectations? The simple answer was you, the one who developed it and it’s something that always plays over in my head when I’m working on a project, especially those ones I do at home.
I’ve been paying extensively for rework with my latest forays into the world of game development. My regular readers and Twitter followers would’ve noticed that I cheerfully announced my success in cracking the stable orbit problem. Indeed in a round about way I had, basically my Unity scripts would push the planet around until it hit a stable orbit and afterwards would calculate the required velocity before turning off completely, letting the heavenly body orbit in a near perfect circle around its star. This worked for the 2 planets I had in there but unfortunately the equations I had developed didn’t generalize very well and adding in planets at random locations with random weights led to all sorts of wobbly orbits with planets meeting both fiery deaths and cold extinctions at the cruel hand of my orbit stabilizer. I was back to square one and I spent most of the weekend trying to figure out a fix.
Eventually I came back around to the idea that my smart-ass subconscious came up with a while ago. I had tried to implement it before but I gave up in frustration when the results I got were no different than from my far more complicated “find the angle between the sun and body, increment it a bit, find the new position, create a vector to it then apply force in that direction” when in reality the fault lied in the orbit stabilization code. All that pushing and pulling that made the orbit look stable was in fact imparting all sorts of wild forces on the poor little planet, when in fact the best way is just to simply let gravity do the work for you. With this in mind I re-implemented my perpendicular force calculations and then devised a rudimentary equation that combined the mass, radius and a fudge factor that let me hand stabilize the orbit. In the past attempting to do this stuff manually took me an hour or so per planet, with this revised code I was able to do one in minutes and have developed a new equation that is able to accurately send a planet into a stable orbit no matter where I place it in the game.
This solution was far more simple and elegant than what I had been trying to do previously but the cost in terms of rework was tremendously high. I’m lucky in this respect in that the client for this is just myself and my friend at the moment but had this been for someone else with whom I had a contractual relationship with that kind of rework would’ve been extremely costly. Of course I could try to make the client pay for it but ask anyone who’s gone back to a client asking for more money after saying they could do it for a certain price and you’ll usually be laughed out of the office, if not walked out of there by security.
Working around this isn’t easy as clients will usually want to have a strict set of deliverables and time frames which seems to rule out any iterative or agile development methodology. It also pushes a team dangerously towards suffering from analysis paralysis as you agonize over every requirement to make sure it’s covered off in the final product. A healthy amount of analysis is good for any project, especially if it makes the product easy to maintain or modify, but it’s also incredibly easy to fall into a never ending spiral of pointlessness. Thankfully however I’ve noticed that clients are far more receptive to the idea of milestones these days which lines up well with any iterative process, skirting around these problems easily.
Going after the most simple and elegant solution might seem like the best idea at the time but in my experience it’s those kinds of solutions that take the longest to achieve. It’s almost always worth it, especially if all you’re spending is your own time, but when you’re working for someone else they might not be so keen for you to spend inordinate amounts of time chasing your white whale solution. This probably explains why a lot of software contains incomprehensible code riddled with bugs, but that’s a whole ‘nother ball game and a blog post for another day.
So I’ve decided to try my hand at being a game developer after spending way too many hours thinking about it and wanting to do something more exciting than developing yet another web application. This isn’t the first time I’ve tried my hand at developing games either, I did a semester long course in games development back when I was in university. That course still rates as one of the most fun and interesting semesters I ever spent there, especially when your games were put up against the harshest critics I’ve ever met: the lecturer’s two kids. After finishing that course however I never really continued to try and make games until a mate of mine introduced me to Unity.
For a straight up programmer like myself Unity is a bit of an odd beast. The Unity editor reminded me of the brief foray I had with 3D Studio Max back in college, as it sported many of the same features like the split screen viewport and right hand column with all object’s properties in it. It’s very easy to navigate around and it didn’t take me long to whip up a simple littlesolar system simulator, albeit one that lacks any form of gameplay or semblance of realism. Still being able to go from never having used the product before to making something that would’ve taken me weeks in the space of a single weekend was pretty exciting, so I started about working on my game idea.
So of course the first game I want to make is based in space and the demo I’ve linked to before was the first steps to realizing the idea. It was however very unrealistic as the motion of the planet is governed by simply tracing out a circle, with no hint of gravity to influence things. Additionally the relative sizes and distances were completely ludicrous so I first set about making things a little more realistic to satisfy the scientist in me. Doing some rough calculations and devising my own in game scale (1 unit = 1,000KM) I made everything realistic and the result was pretty tragic.
The sun took up the vast majority of the screen until you zoomed out to crazy levels, at which point I couldn’t find where the hell my little planet had gotten off to. After panning around for a bit I saw it hiding about 4 meters above the top of my monitor, indistinguishable from the grey background it sat on. Considering this game will hopefully be played on mobile phones and tablets the thought of having to scroll like a madman constantly didn’t seem like a fantastic idea, and I relegated myself to ditching realism in favor of better gameplay. My artistic friend said we should go for something like “stylized physics”, which seems quite apt for the idea we’re going after.
It might seem obvious but the idea of suspending parts of reality for the sake of game play is what makes so many games we play today fun. The Call of Duty series of games would be no where near as fun if you got shot once in the arm and then proceeded to spend the next hour screaming for a medic, only to not be able to go back into the mission for another couple weeks while your avatar recuperated. The onus is on the developer however to find that right balance of realism and fantasy so that the unrealistic parts flow naturally into the realistic, creating a game experience that’s both fun and doesn’t make the player think that it’s an unrealistic (or unfathomable) mess.
I’m sure my walk down the game developer road will be littered with many obvious-yet-unrealized revelations like these and even my last two weeks with Unity have been a bit of an eye opener for me. Like with any of my endeavors I’ll be posting up our progress for everyone to have a fiddle with over in The Lab and I’ll routinely be pestering everyone for feedback. Since I’m not going at this solo anymore hopefully progress will be a little bit more speedy than with my previous projects and I’ll spend a lot less time talking about it