This is likely my last post for a while, though I’ll try my best to keep this blog up to date over the few weeks, it’s not super likely – between visiting family in another state and having extra work, it’s more than likely to slow down. This post is just going to be a brief recap of the trimester; a sort of postmortem for the last 13 weeks, but in much less detail than the postmortem for my actual project (posted further down the main page).
Straight up, I loved it. Our university is following a much more practical unit outline, and I think every student benefits from this a thousand times more than the previous version. There’s a greater focus on industry simulation and networking, which is absolutely necessary.
My lecturers were both great, too. In the past I’ve had lecturers that were a little too close to their namesake, and hardly let the student do their own work – conversely, I’ve also had lecturers who did very little. This trimester, my lecturers were helpful, easy to contact, and taught me a whole lot, as well as acting more like friends than teachers, something more lecturers could stand to do.
The workload was mostly based around planning and creating a single project, while meeting milestones along the way. I took the role of project manager, as well as designer, and enjoyed it all. We had some issues (as mentioned in the postmortem), but it was mostly great.
I hope the next trimester is as successful as this one, and by all accounts it will be. I’m still looking forward to a three week break, though there’s a good chance we’ll start pre-production on our next project before the trimester begins.
Thanks for reading!
Winning is an essential part of games – that artificial euphoria from overcoming a pre-programmed challenge is what runs a billion dollar industry. But to accommodate that feeling, we need the threat of the opposite – of failing. Most games today tend to do as much as possible to avoid the “fail-state”, whether by subverting it completely (such as in the Prince of Persia reboot) or by simply making the game exceptionally easy. Of course, the problem here is that there’s a total lack of satisfaction; you don’t enjoy overcoming a challenge if there’s no challenge to overcome.
More than that, the player’s learning is stunted if they have their hand held for too long. When I first played Minecraft, it took me about an hour and a half to realise I could break more than just dirt, and I don’t think I’ve enjoyed punching trees as much since. Compare that to most modern games where I’ve had to sit through a several minute tutorial (even if they’re optional) just to make sure I haven’t missed any innovative new feature (spoiler warning: I haven’t).
Inevitably, a post about subverting modern game design is going to mention Dark Souls, and this one’s no different. Dark Souls had a bare-bones tutorial, relying on throwing players into the deep end and teaching them the hard way. While I believe the games could stand to teach players a lot more than they do (such as the weapon scaling mechanics), it’s this trust in the player that makes the games shine so brightly.
By trusting in the player to learn for themselves, we encouraged them to explore. Having a mechanic explained to you is never satisfying – working it out for yourself is satisfying every time you encounter it for the rest of the game.
It’s interesting to me how this came about. NES games (and anything earlier) were perfectly happy to let the player fail, likely a holdover from the arcade era, in which players failing was the primary source of income. Then we moved on to home consoles, and “evolved” to more complex tutorials, allowing players to learn game mechanics more ‘safely’.
Now though, I wish we’d take a step backwards. Many developers are afraid of players being turned off by difficulty, and this is something I predict occurring more frequently – it’s a very real issue developers face in the mobile market, where the first few moments of a player’s experience are so essential. As the industry is more and more influenced by this market, games will likely only get easier and easier, which I think is detrimental to them as a whole.
Games represent a unique challenge in storytelling mediums, forcing players to overcome some kind of trial or tribulation to finish a narrative, and this is what makes them so compelling. The further we move away from this, the less unique and distinct games become.
This post may be a little off my usual topics, but I’ve been playing an unhealthy amount of Mortal Kombat X and it’s been on my mind (that, and I’ve been seeing loads of posts online about this). Now, I’m not a hardcore player of fighting games, as I don’t have the time to spend learning the ins and outs of each (because I’m too busy playing other games). However, I’ve played many, and enjoyed them immensely; though one common theme runs between every series of fighting game, and it used to annoy the hell out of me. Spamming!
Spamming is when your opponent (another player, in this case) keeps as far away from you as possible, and uses the same projectile attack over and over (“spams” it). This is annoying because it breaks up the typical flow of a match, and if you’re inexperienced can lead to losing in (what feels like) an unfair way.
Even if you’ve never fallen victim to this tactic, you can probably imagine how annoying it is. Your opponent is too far away to hit and they’re slamming you with fire / knives / bullets / whatever, which means you never even get the chance to land a hit on them before you’re dead.
So, why do I think it’s okay? Firstly, I should reiterate that I think it’s okay. It’s not great, it’s not good, it’s not awful, it’s okay. It’s bearable. It’s not a real issue. One of the reasons I think this is because if you’re losing to a spammer, frankly, it’s because you’re atrocious at your chosen game.
Fighting games – like all competitive games, really – are about predicting your opponent. Typically, if you can do this, you can win. So why do spammers ever win a match if they’re literally using the one move?
This changes from game to game, but I think it comes down to a lack of understanding of basic fighting game mechanics. I’m yet to play one that doesn’t accommodate a way around this kind of technique, and I doubt I ever will. Admittedly, they range from simple to more complex depending on the game, but you can always fall back on the trusty block.
Take Street Fighter 4, for example. One frustratingly common tactic was “turtling” as Guile. This meant that the opponent (playing as Guile) would sit as far back as possible and launch his signature attack, “sonic boom”. When you got close he could hit you with this crazy backflip kick and start the whole thing again.
That is, if you couldn’t find the block button. It’s true that you typically take “chip damage” when blocking an attack in most fighting games, but it’s usually negligible, and it also prevents you from being knocked off your feet.
Going further, SF4 allowed players to totally avoid damage if they knew the mechanics by using something called a “Focus Cancel”. By holding down two buttons, the player could initiate a Focus Attack. This was a slow moving attack that dealt a good amount of damage, but more importantly, would absorb the first hit made against you while you were attacking, and would heal the damage from said attack over a small amount of time.
Typically, this was used to absorb a quick punch or kick before your focus attack landed, but there’s more to it – by quickly moving forward while focus attacking, your attack would be cancelled. This allowed players to “Focus Cancel” – quickly activating and cancelling a focus attack to absorb a hit. This could be done endlessly, though if you were hit for real (or hit twice during a single focus attack) all of the cumulative unhealed damage would be dealt, meaning you’d essentially lose the match.
On top of that, there’s also the simplest – dodging. While this is more effective in 3D fighters, side-scrollers like Street Fighter and Mortal Kombat still allow players to jump or duck attacks that they couldn’t or didn’t want to block.
So, why is “spamming” considered such an issue? I think it’s because it stops the matches being as fun. A great fighting game match comes down to each player trying to predict the next move and acting appropriately, leading to tense edge-of-your-seat moments, but because spammers are so predictable, it quickly becomes boring.
Over the course of writing this, I’ve changed my mind – spamming is not “okay”. It’s kind of shit, but only because it leads to a boring, easy win, and if you’re bored when you’re playing a video game, you really are wasting your time. I stand by the notion that it’s a legitimate strategy, and if you’re losing to a spammer it’s because you’re on the lowest level of skill (no offense intended, but it’s the truth). However, I can’t empathise with people that do spam – it doesn’t seem fun for either party.
Mechanically, fighting games are extremely tight – tighter than any other genre, I’d say. Each animation and attack is looked at down to the frame and balanced carefully, so it should be no surprise that spamming isn’t something that can just be disabled. Games already do mitigate it as best they can, but as long as you have projectile attacks, you’ll have spamming. Learn to deal with it, and try not to do it if it bothers you this much – just remember that it’s easy to play around once you’re a bit more practiced.
Working for a company that deals largely in mobile development, monetisation is inevitably something at the forefront of our concerns when designing. Unfortunately, the only thing we prioritise more highly is making great games – and these two things can be hard to mix well.
I’ve recently been playing Final Fantasy: Record Keeper. It’s a free-to-play mobile game that takes place across multiple worlds from the Final Fantasy series, and it uses one of the most frustrating monetisation systems I can imagine; which is also one of the most common.
This is the “stamina” system, in which players can only play a certain amount of a game before they need to “rest”. For example, completing a quest in a game may take 10 stamina, leaving you with 30 – when you run out, you’ll need to wait until your stamina regenerates, at a rate of a few every 10 minutes or so (depending on the game).
This, frankly, shits me to tears. It’s my belief that any game – whether free or not – should be able to be played at the player’s discretion. Everybody has a different schedule, and even though some people may put less hours into games all up, their schedule might mean that they have to play it all at once, which isn’t possible with a system like this. I hate the idea of taking control away from players to make more money.
However, money is obviously essential. While we’d all love to make games without having to worry about making money at all, it’s not viable for anybody. Higher income means more (and better) games, as well as the continued survival of the development team, which is fairly important too.
It’s the Stamina system I have an issue with, not the concept of monetisation. Free games definitely need to compromise somewhere along the line in order to be profitable, but I feel as though they’re not exploring their options enough. More often than not, games settle for these Stamina systems, or one of a few other archetypes; the ‘premium currency’ that grants access to special equipment / levels / characters / items, an onslaught of advertisements, and a few more.
People have found varying levels of success with these systems by tweaking numbers, with some almost being bearable. But, at least for me, free-to-play games always run themselves into the ground because of these systems. If I feel like I can’t succeed at a game without spending money, why would I spend money? It could happen again in the future when more updates roll out, and there’re plenty of other games out there. Why would I spend money to instantly regain my stamina? As I’ve said, there’re plenty of other games to play.
It’s not easy, though. Games need to be make money, and they need to be competitive (especially on mobile devices, where the competition is absolutely immense). I’m not saying that I want monetisation to go away – I just wish developers would experiment with ideas a bit more.
If anyone knows of games that make money in interesting or unique ways, please let me know; either through the contact page, or by commenting on this post. Thanks for reading!
Roughly nine weeks ago, three other design students and I got together and planned out a game to make for the rest of the trimester (eventually, we were also joined by two audio designers and a programmer). After much deliberation, we decided on a first-person exploration game with a heavy focus on narrative, utilising the Oculus Rift. We decided to build this in Unreal Engine 4.7.2 – at the time, Unity 5 had only just been released, and we decided to go with UE 4 because of the improved visuals and easy Oculus implementation (as well as a few other reasons, mentioned below).
Reverie – the name of our game – tells the story of a woman who’s been a serious car crash, and allows the player to explore an abstract imagining of the events leading up to this collision. The following is a relatively brief list of what I feel went right, what went wrong, and how things could be improved in the future.
Despite some (honestly, quite serious) technical hiccups, I think a lot went right, and our final product is something I’m proud of. Our team of attractive stock photo models (pictured above) all worked well together and collectively we’ve all put a lot of hard work into Reverie, which I believe shows. I’ll detail what I felt went right during development in this section.
This is kind of an easy one – everyone thinks their ideas are good, but honestly, I think Reverie really is a good idea. The idea of exploring surreal landscapes to get clues about what happened and led to this point is something I’ve always loved, especially in that it’s an experience unique to games as a medium (that is, environmental storytelling). Reverie was an idea that was both interesting to play and develop, while being reasonable in our time frame and skillset, and I consider it a big win.
It was easy to develop because it was very light mechanically, meaning we focused mostly on level design and asset creation, allowing us to make a relatively large game quite quickly (again, about nine weeks). Developing a game with a focus on narrative without any written words and only a handful of voiced lines was also a great experience, and I think it’s safe to say that each member of the team learned a lot during the course of development.
While we did have some technical issues with UE4, most seemed to stem from us, rather than the engine itself – and the game couldn’t have turned out this well on another engine. The easy Oculus Rift implementation cut down on programming time (because there’s literally none, UE4 supports “plug’n’play”) and the engine is simply beautiful, which is a great help for a project like this one. We’ve also learned a lot about the engine, and since most of the team was more experienced in Unity, I think this was a big win all round. Learning a lot about a new engine and having the product look better was worth the pain caused in the final hour of development (which I’ll stop alluding to and let you read about below).
It was because of our inexperience with the engine that ultimately pushed us to choose it. We were initially blown away by the visuals and ease of some features, but having used UDK previously, we were well aware of some potential issues. It was because we wanted to gain experience with new engines that we settled on Unreal, as we would have potentially learned much less if we’d gone with Unity 5.
As a team, we worked well together. All the designers and the programmer were in constant communication throughout the project, and without such a level of communication this project wouldn’t have been possible. Any potential issues were brought up and discussed immediately, and ideas were thrown about freely. Nobody had any issues with other teammates, or if they did, they didn’t bring it up or let it affect their work. It was said from the beginning that if someone were to have issues, they should bring it up, and the fact that nobody did is (mostly) encouraging. Amongst the designers and programmer, there were no hiccups in communication or teamwork.
While this could probably fall under “The Idea”, I felt enough extra work was done on scoping the game to be worth mentioning it another section. Our game consisted of five major levels – a hotel, a museum, a garden, a barn and a lighthouse. However, only the hotel, museum and lighthouse were truly essential to the plot. Cutting any of them would have been a shame (and we didn’t have to, the garden was completed way ahead of schedule and the barn made it in, though barely). We decided on a priority, with the barn at the lowest end – as a result, the barn did make it in, but it was missing half of the features we’d envisioned. Still, it’s better than no barn at all, and it’s thanks to this scoping and prioritising that the project made it to the level of quality that it did.
At the outset we knew we were going to be pushing it for time, and we were – but almost all of the content we wanted made it into the game, which is rare for any creative project.
Audio is a large component of Reverie, as it encompasses all the player cues (which was a mistake we were aware of, but never had time to fix) and a decent chunk of narrative clues. We immediately realised that audio was a high priority, and went about recruiting two audio designers to the team, for both design and implementation.
Unfortunately, things went astray. They both ended up having to defer for different reasons, and weren’t able to finish the audio – unfortunately, this happened relatively late into the project, meaning we had to scramble to get the audio done ourselves. We found great success in FMOD, which enabled us to quickly insert and edit audio into the game. Unfortunately, we didn’t account for FMOD’s weakness; when opened on another machine, Unreal requires FMOD is installed for the audio to work.
This wouldn’t be an issue once the game was built, but because we had four designers and a programmer, it was a problem. We barely managed to get our audio in the game at all thanks to a last minute rush, and even then none of it was polished to a high level of quality.
Optimisation hasn’t been at the forefront of concerns while developing games at university – in a workplace environment, it’s much more important, because games need to run on multiple devices. At university, however, it only needs to run on a single fairly decent computer (maybe two or three at worst), so optimisation quickly falls to the bottom of the priority list.
At least, that was the case with Unity. Unreal 4 quickly becomes much more demanding, and the file size grew exponentially out of control. We managed to cut down on this eventually, but we could have saved ourselves a lot of time during development by keeping a closer eye on optimisation.
This was the big one, and it ended up screwing us pretty hard (excuse the non-academic language, but it’s apt). At the end, just before our first exhibition, we tried to package the game – and nothing. The package failed. We ended up trying on four different machines between us, on different copies of the project, and nothing.
We’re still not sure what the exact issue was – according to trust Yahoo answers, Epic Games is “aware of the issue and looking into it”, which is a few miles south of reassuring. This may have been (and probably was) our fault, rather than the engines, but having no idea what could’ve caused it or how to fix it was a nightmare. At the time of writing, this issue hasn’t been fixed, and the project is, sadly, impossible to package. Possibly in part due to our poor…
Engine Version Control
When we were writing the Game Design Document (or GDD), we knew what every game designer knows – the team should only work on a single version of whatever engine you were using. In this case, we’d all decided to work on Unreal 4.7.2, as that’s what the computers on campus were at the time (at the time, it was also the latest version).
Unfortunately, some members of the team had the misfortune of having Unreal update itself, which was a problem compounded by the computers at university inexplicably being updated to a much newer version mid-trimester (if you’re reading this, person-in-charge-of-updating-computers-at-university, please put a stop to that).
In the end, we all updated to the newest version, but the damage was well-and-truly done. We didn’t run into any obvious or major compatibility issues (the minor #.#.X updates aren’t so bad), but there’s still every chance it caused some of our issues.
As usual, this section essentially explains that we’ll avoid doing the things listed in the “what went wrong” section while continuing to do the things in the “what went right” section, but with a bit more detail. As should be the case with every project, whether at university or otherwise, we’ve learned a tonne from creating Reverie.
Control The Engine Version
This was, possibly, a huge issue. It’s not anyone’s fault, but it’s something we need to keep a much closer eye on in the future. It’s partially because UE4 is a nightmare to roll back to an earlier version, meaning if something updated automatically or accidentally, we were out of luck. We’ll need to see about Unreal being updated on campus, but working from home, I’m confident we’ve all learned how important it is, even if we haven’t quite figured out the best way to go about controlling it yet. It’s not as straightforward as simply never updating when we’re using several machines, some of which are public – avoiding these computers altogether isn’t really an option, either.
Mitigate Personnel Issues
We didn’t have enough plans in place in the case of team members dropping out, and that ended up hurting the project. Since we lost two audio designers, the audio suffered – this is a bit of a no-brainer, but it suffered more than it needed to due to lack of preparation. This is a simple one that always comes up; plan more. Or rather, plan efficiently – team members leaving or being unable to work is an issue that needs mitigating immediately, so future planning needs to be prioritised with this in mind.
Package Early, Package Often
This probably wouldn’t have fixed our issue, but it would’ve allowed us to pinpoint it. We still don’t know exactly why the packaging is failing, and packaging early to have multiple builds could have helped us immensely. This goes back to the planning – package milestones should be set up, so we get a new packaged build every two weeks or so.
And, that’s it! I’d like to write a more detailed post, as not everything I wanted was in here, but I’m nearly the 2000 word mark and have too much to do! Thanks for reading.