This is our last weekly blog post before Fragmental is released to the public on Steam Early Access on Monday 29th February.
So, I thought it would be good for today’s blog to have everyone on the team tell you what their role was, what they contributed to the game, what their experience of working on the project was and what their hopes are for our baby after we release it out into the wild.
I’ll kick things off then let the guys say their bit.
Billy Thomson – Creative Director
My main role is to provide overall direction to the team on any creative content that we add. Game Design, UI Design, Level Design, Art, Audio and Marketing Materials. It sounds like a lot, but as you’ll read below, it’s the team that does all the real hard work. Most of the time I provide initial direction then simply review the work that’s carried out by the team until we’re happy to sign off and say the task is complete.
I also created a few of the Maps in the game – Dave, very kindly and affectionately shouts “dogshit” whenever one of them appear during a game. I defined the Weapon and Modifier Rule Sets, and tweaked the setup for player movement and a bunch of the weapons.
Other than that I’ve handled the social media side of the project, annoying everyone with constant Facebook and Twitter updates and blog posts. You’re welcome by the way…
Ultimately though, my main job is really just to keep the team heading in the same direction at all times. This is normally a ridiculously difficulty task on a game project, but this fantastic team have made it very easy for me on this one. I have to say it’s been my genuine pleasure to work with them on Fragmental, the project that has been a dream to work on and the game is the most fun of any I’ve helped create in 20 years of game development.
I’m tearing up a bit now, so I’ll pass the keyboard and let the team take over.
James Cope – Producer
I came onto the project once the core game was demonstrable in prototype form. My main role has been to help steer the game from prototype to releasable product, essentially helping to make sure that we had a development schedule where we could prioritise features for the game’s release on Steam Early Access. Now that we’ve got to that point of release, it’s both a jubilant moment and a sad one as I have to focus my efforts on something else and watch Fragmental sail away on its successful voyage.
I love twin-stick shooters – I hold Robotron up as one of the very best games ever made – so Fragmental is right up my street in gameplay. I also love couchplay games like Mario Kart and Super Smash Brothers so Fragmental’s combination of twin stick shooter and fun, social, couch gaming is something I’m very excited by. It’s been absolutely fantastic to see Fragmental develop from a rough (and quite different) prototype into what it is now. It’s one of the most fun games I’ve been able to work on, and certainly the most fun to play. Running and gunning will always be great fun for me but Fragmental’s fast, frantic and competitive arena style combat adds an additional layer of skill and reward that I love.
Unfortunately I am genuinely terrible at playing the game, I have probably thrown away a lead in a game more than anyone else so far. My biggest regret in the project has been not beating Steve more often.
Duncan Harrison – Technical Director
What with Dunc being our Technical Director, it’s not entirely surprising that he was too busy working on another project to write anything for this today, so I – Billy – very kindly said I would cover for him. I can bang the 1 and 0 bongos as well as the rest of them, so why not, what’s the worst that could happen, eh?
Dunc has pretty much taken our entire prototype game – which was almost entirely created using Blueprints – and pulled it all back into code, so that we can get the networked game to, well, actually work. He’s had has hands on most of the team’s assets at some point – thankfully he has warm, caring hands – and he has been quite fond of phrases like “that’s totally fuckin boned and needs entirely re-written”, “that blueprint that you’ve written is all kinds of fucked, Martin”, and my personal favourite morning update “well it was all totally fucked, so I had to un-fuck it all”.
Ladies and gentlemen, I give you our Technical Director, Dunc. Undisputed Master of the 1 and 0 Bongos.
Graham Hughes – Systems Engineer
I’m the latest addition to the team and it’s been pretty awesome working here. Everybody has a good work ethic and people are always looking for ways to make the game better.
Most of my work so far has been to add animations, fix weapons, and add melee to the game. I’ve put quite a lot of time into making weapons a lot more flexible; so you can probably expect some stupid shit pretty soon.
My job in a more general sense is to work on new gameplay features. I’m currently working on AI, which will hopefully make the game a little more fun for billy no mates. Which is good, because billy’s basically my boss.
But for now they aren’t so much AI as merciless killing machines. (Until they run out of ammo, when they become about as threatening as a litter of kittens.)
Simon Kilroy – Game & UI Engineer
It’s always fun being asked to write about the stuff you worked on as a project nears completion. You’d think after spending months on a title it’d be easy to remember things but one of the cooler aspects of working on a smaller scale project like Fragmental is that you get to touch on a whole bunch of different systems. This is where Perforce changelist descriptions are *really* helpful.
So, as the title of my role suggests, I concentrated mainly on gameplay and UI systems during the project. In the weapons systems I built upon the original designs to add throwing weapons, fragmentation, spawning and pickup systems as well as the force feedback setup when firing. On the player side, I worked on improving sprinting, aiming and how they handled travelling through teleporters. Player shields needed a pretty massive rewrite after their initial VFX-only addition. Note to self, I can see why most games go with an over-shield type implementation…
Environment wise, the destructible balls that can ruin a perfectly good kill streak? Yep, fixed those up. The doors which can either save you from death or cause your perfectly lined up Flak shot to rebound into your face went in on my watch too, sorry. Then there was more general tasks like code support for art and design and an engine upgrade done along the way too which went far better than I expected, cheers for that Epic.
Finally there was the slightly less glamorous yet still super important UI and Frontend work. That ranged from communicating player death/kill info on the HUD to setting up the Lobby and Options screens in the Frontend as well as the save system used to store all that info. I’ll leave it to you to decide what I had more fun working on
Alex Porter – Game & UI Engineer
As a gameplay and UI engineer, as well as being a newer member of the team, I tend to work on a little bit of everything, minus some scarier systems work which I try not to think about too much. I work with the various artists and designers providing code support on everything from levels to weapons to the multitude of elements that make up the in-game HUD. Importantly I built the kill log displayed at the end of rounds which goes a long way to answering the previously impossible questions of who killed who with what in what order, despite this being a perfectly functional system “bullshit” is still called on numerous occasions by those feeling unfairly deprived of frags.
One of the upsides to working on a smaller team is that I’ve been able to have a hand in areas other than programming. I’ve designed a level which was then built by Dave, created several odd weapon prototypes which may never see the light of day, been involved with various discussions on game modes, level layouts, melee controls and more I’m probably forgetting. For someone with a healthy interest in design it’s great to be involved in that side of development and certainly not something I was expecting for my first project as a professional developer.
I am also currently the Fragmental office champion, holder of the prestigious cans-taped-to-a-box trophy presented at the end of our first live-streamed tournament, much to the displeasure of one Billy “Not bitter in the slightest” Thomson, the Fragmental tournament runner up.
Bert McDowell – UI Engineer
I have been helping out on the project try to sort out the UI by coping large amount of code from the unreal engine and bashing my head against the keyboard until it works.
In all seriousness I am an experienced developer with years of experience under my belt. Its been a fun project to work on and the office has been really lively when ever Fragmental is played. Some day I’ll get more than 3 kills. 😉
Steve Banks – Lead Designer / Noise Maker
My role concerns all things design. Creating prototype maps, polishing maps to a shippable level, blueprints and discussing overall game design. We have a great design team on Fragmental and everyone was given creative freedom to create anything their imagination dreamed up. The end result was a set of varied, but really creative maps that were fun to make and great fun to play. Some great Level Design has really lifted the fun factor in the game and they have stood up against some intensive playtesting over the duration of the project. We still enjoy playing them now and hope you will too.
My sub role on Fragmental was making noises. Not the sweary kind when playing (although I’m pretty good at that) but Game Audio. I created all of the SFX for the game and also the Front End music track. There are a lot of weapons in the game so it was quite a challenge to get them sounding varied and good. I’m also pretty happy with how the voice over sounds considering it’s all synthesised. We have some great music tracks written by Sung and hopefully I’ve added to the aural experience.
Dave Hoare – Designer / Level Designer / Tea Lady!
My main role with Fragmental was to create the Battle Arenas for the game (Maps basically but Battle Arenas just sounds cooler). I’ve created more than half the Maps in the game so far, which makes it fun when you’ve to go back and clean them all up for final release!
It’s great fun working on Fragmemtal, the team are some of the nicest and most talented guys I’ve worked with, and we’ve put a lot of love into making this game.
The game has turned out to be a really fun couch play experience, and hopefully the gamers will get the same enjoyment from playing it as we have had creating it.
Martin Livingston – Level Designer / Assistant Producer
Like most of the guys on the team, I have a few roles I fill depending on what needs done at any given time.
Most of my time has been spent on map creation, specifically a lot of the survival maps. We’ve been given *almost* free reign to go ahead and create whatever weirdness comes into our heads, and I like to think my brand of weirdness is touched with genius. Billy would probably say its madness. The coders would certainly say it’s just plain broken as I have an eerie ability to make a level work, while somehow breaking the laws of physics. For that reason as lot of my levels will appear in future updates after the initial Early Access launch, as there may be a tiny bit of work needed to ensure they don’t break the game, or create a wormhole and end the universe. That kind of thing can happen when you fuck with physics.
On the production front, I’ve spent quite a bit of time opening communication channels with a view to marketing Fragmental. We’re self publishing, so mutually beneficial arrangements such as supplying YouTubers and Twitch streamers with Steam codes has been one of my main tasks. Obviously there is some risk there as once the code is sent, its completely out of our hands, and if they hate it then they’ll make that patently obvious in their channel, but so far it’s looking really positive.
Going forward I’ll be taking on a more production focussed role as we take the game from Early Access to Full Release through a number of regular updates.
Finally, and for me the most enjoyable part of the job, I’ve tried to make it to as many of the public showings of Fragmental as possible. Seeing people’s reactions to the game is the ultimate validation of the entire team’s efforts, and it’s a credit to the guys that there has not been a single bad response yet!
Anyone who’s read my previous blog posts will know I tend to veer off topic wildly, and go a bit Leftfield. This post has gone the opposite way, so I’m going to shut up now before it gets to dull.
Richard Ralfe – UI Designer
There’s a saying that if you have to explain how your UI design and flow works, then your UI design doesn’t work or flow.
Whilst the Early Access version is as streamlined, punchy and fun as we can make it, there’s a helluva lot of wonderful customisation, great new content and loads of other features in the pipeline to keep Fragmental fans happy for (hopefully), a long time.
All of that has required a significant amount of design (and redesign) to make it work and give players control over how they play Fragmental – to ultimately make it their game, not ours. The best is yet to come…
Gary Whitton – Animator / UI Artist/ Marketing Monkey
My main role at Ruffian is usually an animator but it’s been a bit of a mixed bag on Fragmental; also being responsible for the majority of the UI artwork. There’s still a good way to go with this yet but it’s definitely moving in the right direction.
I’ve created most of the promotional art that Billy and myself have been spamming the shit out of on social media. It’s a pretty easy task when you’ve got cool characters to work with though (courtesy of Paul Large).
I worked with Tom on the weapon designs, which I covered in an earlier blog post, and created the models for the powerups. I also came up with the “Fragmental” name which is pretty cool. I do love a good pun though.
It’s been an absolute blast working on this game (told you) and for the most part it hasn’t really felt like work. I know you’re probably not supposed to say this sort of thing but it’s a fucking great game. It is without a doubt the best thing I’ve worked on.
It’s a bit nerve-wracking releasing this into the wild but I think we’ve created something which we all love and that’s just about the best you can do. I’m excited for people to play it and hopefully we can take it from strength to strength through early access with some good old community feedback!
Neil Macnaughton – Technical Animator / Technical Artist / One Man Band
Neil’s in the same boat as Dunc is today, busy with another project, so again I – Billy – will try to summarise his role on the project.
He’s traditionally an animator, but over the past few years, he’s turned into a bit of a one-man-game-making-band. On Fragmental, he’s created complicated environment materials in blueprint, setup our entire lighting and post pass, created the rig for our character and skinned the model for animation, created weapon models, created all of our VFX, re-written some insane designer created level blueprints, written the material for our ammo HUD, setup and created a lot of the content for our animated in game level background, created the Power Gloves from scratch, created the materials for our death spheres, and he’s even done a few animations – told you he was an animator!
Kev Black – Lead Test Engineer
Hello! My role in the Fragmental development process is to outline our testing procedures and schedule running from our first playable build to the release of our Early Access version – which is now available – and beyond!
Our internal two man QA team is responsible for ensuring the final product is bug free and working correctly, hitting all of our Early Access features, in one build and every facet and mechanic of the game is works correctly and as intended.
As we progress through development of the game, we are continually testing new features that the rest of the development team are working on, and ensuring that they’re issue free before merging the new content over to our Early Access branch.
So, as Fragmental progresses through the Early Access phase of development – heading towards full release, the internal QA team are working with new experimental features, providing design feedback and methodically documenting and testing every individual feature before it’s ultimately made available to the public to enjoy.
Paul Conry – Senior Test Engineer
The most important part of my role on the project is to ensure that all bugs (as humanly possible) in the game are found, reproduced, submitted, and ideally resolved, regressed, verified and closed. That in turn leaves us with an end product which is a known quantity, which is stable and one which we have an awareness of the vast majority of pertinent bugs that remain; thus feeling good about releasing it into the hands of the gaming public and press. I work directly with all members of the team from the Studio Head to the Producer and occasionally to the public and press at events.
A certain part of being in Test is suggesting improvements and changes in the design of the game, and several of mine have been implemented into the game itself. I named several of the levels, such as ‘RAT RACE’ and ‘PINBALLS’ and my suggestions on level design have helped shaped the levels we play.
In Test, we arguably play the game more than anyone else and notice subtle changes and issues with the game. We pride ourselves in ensuring all these issue are reported and argue our case to have as many of them fixed as we can. I’ve been told I’m very passionate and tenaciously debate a bug be fixed if I think it warrants it. I’ve been called a ‘Legend’ and also a ‘Grammar Nazi’ during development, as well as a ‘Ratweasel’ during playtesting; but that just proves we’re doing our job right!
Well done for getting to the bottom of that absolute monster post!
Fragmental is out this Monday – 29th February – head over to the Steam page and add it to your Wish list!
We Have a Release Date!
After nearly 7 months of development, the Fragmental team are ready to release our baby to the gaming public on Steam Early Access.
Pwoud, Vewwy Pwoud
Fragmental is probably the smallest project I have ever been involved in, but it’s also been the most enjoyable, rewarding and exciting thing I’ve ever worked on.
I know that people who are Lead Designers, Game Directors, Creative Directors and all those other leading roles are supposed to say good things about the games they make, but this is completely genuine. I absolutely love working with this team, and I can’t get enough of the game that we’ve made.
In my 20 years of game development, I’ve never had so much fun playing a game that I’ve been part of creating, and that gives me an enormous sense of pride in what we’ve made.
More to Come
So, our Early Access build is complete, and we all love the game as it stands, but that doesn’t mean we’re finished.
We still have a lot of content and features to add before we can say the game is complete. We’re already hard at work on our first update, and our goal is to release regular updates every 2 to 3 weeks.
We’ll be using our Steam page to keep everyone up to date on the progress of these updates, and we’ll provide more details about our current roadmap plans next Friday before release.
For today though, all we really want to do is share the release date with everyone.
If it’s good enough for Chuck, it’s good enough for us!
Just in case you missed it on the first image.
The release date for Fragmental on Steam Early Access is 29th February 2016.
Head over to the Fragmental Steam page now for more info, and add Fragmental to your Wish List – you won’t regret it!
One. Last. Push.
It’s been 3 weeks since our last blog post, and you have every right to wonder why the hell we’ve been ignoring our blog post duties.
I agree, it’s practically unforgivable, but I promise you it will have been worth it, because we’ve spent all of that time playtesting the glowing, angular arse off Fragmental.
During that time we found a range of bugs, usability issues and aesthetic oddities, and we’ve been fixing as many of them as we possibly can before we finally release Fragmental on Steam Early Access.
Holy shit, just writing that down made my stomach flutter a wee bit there!
Playtest, Bug Fixing and Refinement
As I briefly mentioned in a previous blog post, we’re lucky enough to have the fantastic Abertay University just along the road from our studio, and it just so happens we know most of the lecturers on their Game Design & Production Management course. So they very kindly asked if anyone from the course would like to spend some time playing Fragmental for us, and then provide some feedback. The response was overwhelming, we had over 40 students come in to play the game over the course of 4 full afternoons, and we had to turn down more than double that number as we simply couldn’t handle that many people over the course of 4 days of planned playtesting.
Each afternoon, a different group of students played the game for a solid three and a half hours, constantly switching who was playing after each match. Their reaction to the game was great to see – even the fuckers who refuse to use their Right Stick to aim. Some of them were seeing the game for the second time, so it was really encouraging to hear that the usability and balance concerns they had experienced during their first playtest back in October, were all gone. For the students who were seeing Fragmental for the first time, it was every bit as gratifying to see them pick the game up and get right into the action with no explanation other than the controls of the game.
The last time the Abertay students gave us feedback, we spent the next 5 or 6 weeks of development, focused entirely on the most frequently reported usability and balance issues that they provided in their feedback. To say that their visit and the feedback that they supplied was useful, would be an enormous understatement. So, a massive thanks goes out to all of the students who came along and gave us their feedback.
This time around, their feedback was more directed towards requests for additional features that they might like to see, or minor subjective opinions that we’re not going to work on right now, but we will look into fixing if more players are of the same opinion. Basically there were no major issues with the game, which was a big difference to the previous playtest in October. Result!
All in all, we came out of that 4 days of playtesting feeling really positive about the current state of the build, as well as the work we had put in to solve all of the issues that they flagged after their first experience of playing the game.
We may not have revealed any new major issues during the playtest with the Abertay students, but over the past few months our two man QA team – Kev Black and Paul Conry – have been finding a lot of genuine bugs, and our team have been fixing them as fast as Kev and Paul could find them. Unfortunately as any dev knows, you can end up getting into a bit of a whack-a-mole situation where you end up fixing one bug which then leads to a new one being uncovered behind it. Rinse and bastard repeat.
We’ve been finding bugs and fixing them for the past 6 weeks or so, and we’re in a really good place with how the build looks and plays, it still has some rough edges, but it’s definitely ready for the gaming public to get their hands on the game through Steam’s Early Access.
During the bug fixing period, we were also adding a new Front End and replacing all of the placeholder in game HUD. We’ve gone through 3 or 4 iterations of these and we’re really happy with how it’s all turned out. We still have some more Front End work to do, to add more functionality to allow players to do things like enter their names, and customise their matches, but we think we’ve nailed a look and feel, and we think we’ve got the in game messaging working well for new players. The beauty of Early Access is that the people who buy and play the game, can tell us if we have got this stuff right, and if not, we will do everything we can to change things until we have.
We’ve also done final passes on the Maps as well as overhauling all of the audio and VFX in the game.
The game definitely looks, feels and sounds like a consistent and complete package now, which has been tricky due to our abstract style. Again, we think we’ve got the balance right, but only time and the feedback of the community will tell us if that’s true.
Are We Nearly There Yet?
“Pfff, yes of course we are, totally… well, kind of, we think so, christ on a wireframe bike we hope so!”
As I said, we think we’ve caught all of the major issues in the build, but without a huge amount of testers playing the build for thousands of hours, it’s hard to tell. So, while we’ve done everything we can to ensure that Fragmental is spot on, there’s always a chance that someone, somewhere will uncover something that we’ve simply not encountered. If that happens, we’ll get it fixed and updated as soon as we can. We plan to have regular updates every 2 or 3 weeks, so we’re quietly confident that we’ll be able to keep on top of any issues that the players discover.
Right now, we’re sending out Steam keys to a group of popular YouTubers who have very kindly agreed to spend some of their time, playing and broadcasting Fragmental for us on their channels. We’re hoping for some good reactions to the game, but you never can tell how people are going to take to the games you create and then release. Proper squeaky bum time.
From our point of view, we all love the game at Ruffian, it’s everything and more than what we had hoped it could be when we first started work on it last August. Fingers crossed the YouTubers agree.
We’ll share every Let’s Play video that is recorded when they’re made available to us.
I hope we won’t need it, but wish us luck anyway.
This past weekend, as Martin wrote last week, a bunch of Ruffians headed over to a great pub called Sloanes to show Fragmental off at GlesGames which is a bi-monthly event arranged for fans of multiplayer gaming in Glasgow. It was my first time demo’ing Fragmental in public and we were expecting in the region of 50-100 people to come and play, have a laugh and give us some feedback on the game. It had been a while since the team last put it in the hands of the public and we wanted to know if we’d done the right things in the eyes of players… But hold this thought because I’m about to go on a slight diversion.
Lots of happy faces on the way to setting up a Fragmental demo in sunny Glasgow
I had a scary alert from LinkedIn this week that I’ve been working at Ruffian for seven years. We’ve done some great things in that time and worked on lots of cool stuff that we don’t get to talk about. Conversely we’ve also had some disappointments and embarrassments but so it goes, gamedev has its highs and lows and we surf through them. Anyway! My point is that despite being a veteran Producer at Ruffian I’m a relative newcomer to the Fragmental team. This is my first Fragmental blog post (more to come!) as I’ve been working on other things *cough* Halo *cough* until we decided to put Fragmental into Greenlight. At which point I joined in to help pull some strings behind the scenes and help promote Fragmental by, err, spamming the shit out of every website that’d let us.
I got banned from Reddit. Seriously, man, fuck Reddit.
Anyway. When I joined Fragmental the project was on a bit of a high because we’d gone into Steam Greenlight, it was going well and we all felt that we had an exciting game on our hands. And that is pretty much exactly the worst point in time to bring everyone back down to earth and figure out how we can actually finish and ship the game. In general, game developers are massively ambitious and they try to do too much. Hands up, we’re no different. So the fist thing we had to do was figure out the long term plan and shape of the game, what content we’d release and how everything we wanted to do might fit into a reasonable timescale longer term.
Our first goal was that we wanted to capitalise on the success of Greenlight as quickly as possible and get the game ready for launch on Early Access and I’m glad to say we’re just a few weeks away from that happening in February.
(I was going to write a bit more about the production side of game development here but, by heck, it’s boring to read about spreadsheets. I’m going to talk more about our development roadmap in a future blog post so I’ll go into a bit more background then instead)
Now back to the GlesGames demo we just did. There’s never a good time for a demo. No matter what size your project is, someone will want a demo of your project at exactly the wrong point in time. It’ll be when your build is going backwards, just when that quickly-hacked-feature-that-never-had-any-right-to-work-in-the-first-place falls to bits and you need to refactor nearly every system just in order to do one trivial thing properly. On big games this usually happens about 2 months before E3.
On the smaller indie scale, things will start to go wrong 2 weeks before you setup in a pub ready to demo in front of some Glaswegian gamers. And, at risk of getting pulled too far into stereotypes, Glaswegians aren’t generally known for pulling their punches when it comes to opinion.
Now I’m going to blow the Ruffian trumpet for a bit. The typical scenario for a game being demo’d is that you’d be up late the night before trying to figure out a problem that is usually explained with the words “But it works on my machine”. Not this time. We had a demo build ready a whole three days before the day itself. This is actually amazing and it’s credit to a lot of hard work and experience in the team. To get to a point where, three whole days before a demo, you have build that is stable, shows approximately 95% of everything you wanted it to show and you’re playing it and everyone is laughing you just, well, you just can’t quite believe it’s happening. But it did happen. Everything was great, so we polished it a bit more. And then we broke it. Fixed it. Broke it again. Fixed it. And then it was Friday afternoon with a demo looming on Saturday and I started to worry and it was getting all dramatic and tight and… We spent the entire afternoon playing the game. It was great! We’d nailed it, the build was rock solid, played fantastically well and we were all really excited about showing the game. Hand on heart, this is the first time I’ve gone into a demo feeling confident that the game isn’t going to do something spectacularly stupid in front of a bunch of people. All I could think about was how much fun we were going to have playing it and that is a very rare feeling to have. I’m not suggesting everything else I’ve ever demo’d isn’t fun. It’s just that there’s always been situations where I’ve been stood in front of hundreds, thousands of people knowing with absolutely certainty that if A or B happens, the game will crash or turn itself inside out and make us look stupid, but not this time. Of course, I realise I’ve totally cursed the next demo by raving about all this. Oh well, you’ve got to ride the good waves when they show up.
The first few players of the evening get hands on with Fragmental. Hopefully, BIlly and Gary play nicely.
A good number of people played Fragmental through the evening and we had a nice crowd around our PC at all times which is always a nice feeling. We also got to see old chums and generally have a Good Time. There was a lot of positive feedback that we got and I think it’s best expressed in the way the evening’s Tournament came to a climax in a 79 round epic battle that pushed and pulled between the two players who remained at the end of the evening. You can see the winning moves under the effect of the slow motion modifier with a shotgun kill in the Vine below.
So that’s it for now. I’ll sign off my first Fragmental blog post with greets and thanks to the guys who made GlesGames possible, we had a great time and we had loads of really positive feedback about Fragmental. Watch out for news of our next demos as we’re aiming to be touring around the UK in the coming months to show Fragmental at various events and expos.
We’re going to be giving Fragmental its 3rd hands-on public outing tomorrow night, and this one is easily the biggest test to date of the game that we’ve created.
Our first appearance was back in November, when we featured at “Games are for Everyone” in Edinburgh. This was a showcase for a lot of indie games in various staged of development. Hosted in a pub, with the bar literally 5m away, the setting was pretty much perfect for a game such as Fragmental, and as hoped it went down a storm.
December arrived, and with it came our second public showing. This time the host venue was the Megabytes café in Glasgow, a café themed around games, both modern & retro. This was a slightly harder sell, as people were mainly coming into the venue for a panini and coffee, or just as a way to get out of the lovely Glasgow weather. For anyone not from around these parts, that last bit was most definitely sarcasm.
The Perfect Build
Now into the new year, and we’re currently pushing hard to create a solid, stable build for our 3rd hands-on event, “GlesGames: Galaxy” in Glasgow.
There is a general process that we go through to get the game into a state that we are happy to show off to the public. In the case of Fragmental, this last week has seen us focus on a sub set of content which we know we can easily control, which will also avoid dropping new players in at the deep end. The addition of rulesets has allowed us to increase variation in this focused set of maps by defining different sets of weaponry and modifiers that will or won’t appear in each level. Wait until you play your first Power Glove only level. Or your first, frankly ridiculous, Disc Gun only level. Brilliant.
A big part of this week has also been spent on getting a 1st pass of a cut down Front End implemented. Its fine having debug info or placeholder images everywhere while we’re working on the game in the studio, but its not something we really want end users to have to see. That way we can pretend that everything we do always looks amazing and polished! Gary’s done some great work on the post-round score screen, making it much easier to see who you’ve killed and who has in turn killed you – which are hugely important in a game where Rounds can last 0.5 seconds.
As of today we have locked down the build, meaning that only absolutely critical bug fixes are taken. While I’m currently sat at my desk righting this, the rest of the team are playtesting the build looking for any last bugs that we think should be fixed ahead of tomorrow’s show.
As a company, and as individuals, we’ve gone through this process many times now, but that doesn’t mean it always goes smoothly. Just yesterday we found an evil crash bug that was only fixed through a series of at first glance unlinked suggestions. Turns out if you won a round while still having a Redeemer (manually controlled missile) in flight, then when the next map tried to load it would crash the game due to faulty garbage collection. But of course it would. Obvious really.
I’m getting so much mileage out of this Jackie Chan image. Wonder how I can use it next time?
As mentioned in the opening of this blog, the Glesgames event will be the biggest gameplay test that Fragmental has had for a couple of reasons:
- The attendees should be pretty much slap bang in the middle of our target demographic.
- The other games on show are mostly released games, and they’re a little bit on the good side.
GlesGames advertise themselves as “A local multiplayer video game event, based in Glasgow”. I’ve not been to one of their events yet, but it looks like a haven for hard core multiplayer games players to meet and compete, meaning that a game is going to have to really stand out and bring something new if it’s to garner any attention from all the established multiplayer games on offer. Imagine taking along along your lovely new racing game, then finding yourself set up next to Mario Kart…
That poster doesn’t even give you the full line-up, there are a few standard heavy hitters that don’t even make it onto the advertising:
- Towerfall Ascension
- Mario Kart 8
- Mount Your Friends
- Gang Beasts
- Ultra Street Fighter IV
It would be accurate to say that even with the overwhelmingly positive feedback we’ve received so far, there are still a lot of nerves in the team over this demo, but nerves are good. They push you to work harder and make the game better.
Nerves or no, Glesgames should be the perfect testing ground for Fragmental. Right from the very start when we were pitching concepts internally to the team, I’ve had this memory stuck in my head of the nights my group of mates would finish an evening in the pub, then pile back to a randomly selected person’s house to play Goldeneye / Mario Kart / Bomberman / for hours. It would get loud. There would be shouting. There would be swearing. There would be complaints from other family members about the last two things. (Ally, Paul.D, Paul.S, Mike, Jason – thanks guys!) Let’s do a quick checklist of Glesgames against my teenage gaming years…
- Beers: Check
- Competitive games: Check
- Noisy banter: Check
- Shouting / Swearing: Check
- Annoyed family members: If this happens, I’ll be freaked out
In fact that checklist could pretty much be applied to the Ruffian office as well. Apart from (1) & (5). Actually, sometimes (1), but definitely only late on a Friday afternoon. Here’s what it looks like:
There is a second reason this demo is a big deal for us – it will be a fairly accurate representation of what our first early access release on Steam will be. Unless something catastrophic happens, the levels, weapons, modifiers, game modes and music in this demo will be the same as the ones you’ll see if (when!) you purchase this first build. We have a plan in place for regular updates, but are not quite ready to announce anything concrete yet. As this is completely our own game here at Ruffian, for once we are not bound by publisher deadlines, so if we feel that we need to extend the project length in order to squeeze in another cool feature, budget permitting, we at least have the option to do so.
The question of what to include in the first Early Access build has been one that has been discussed at length in the Ruffian office, and only recently have we reached a consensus that everyone is happy with. Too much content means we delay getting the game out there, leaving little time for feedback from the players and the iteration passes that would follow. Too little content and you guys would (rightly) feel hard done by, and won’t be able to get a true feeling of what the game can do.
As it stands, we’re confident we have the core gameplay nailed down, and most of the future updates will be additional content (more levels, more weapons, more modifiers, more game modes etc), with the remaining non-gameplay features coming online at regular intervals after the Early Access launch (e.g. network play).
The exciting news is that we’re close to releasing Fragmental on Steam Early Access. Keep checking back here for more news regarding this as there will be more information in the very near future!
Hicks: That’s the Grenade Launcher. I don’t think you want to mess with that.
Ripley: You started this. Show me everything. I can handle myself
Yup, that’s another Aliens reference from me. And once again, the link to my article is tenuous, but still just about admissible.
Now that we’re greenlit on Steam, we know without question that we’re going to be completing and releasing Fragmental. While obviously fantastic, this brings with it the realisation that as well as the core gameplay that we’ve been enjoying working on so much for the bulk of the time so far, we’re also going to have to implement all the other less sexy stuff. Like Menus, Settings screens, Localisation, Tutorials…
Learning can be fun.
Of those examples, both myself and Dave are working on the tutorials, and to be honest they are far more difficult to create than any of the normal or survival levels. They’re also traditionally more of a pain in the arse, as the focus has to be more on teaching the player a skill rather than just existing for fun, and even worse, as a designer you are fully aware that a large proportion of the players will play through your carefully crafted tutorial experience exactly once, or worse still, never. In production speak, not much bang for your buck. Tutorials are just generally not fun. Except for Far Cry: Blood Dragon. Well played there Ubisoft.
That said, for every hardcore player that will immediately just ‘get’ your game, there will be a player who likes to be led through a game’s systems and features, so they are armed with as much knowledge as possible before they are thrown into the action. So, tutorials are in.
Principles and Goals
The core principle we’re working to is that everything in this game must be fun. If it’s not, either we find a way to make it fun, or it’s out. With the tutorials, we’re multi-purposing – initially it will be a teaching tool, eventually turning into a set of single player challenges through repeated play. While this two-pronged approach provides more value to the content, it makes the job of creating it that much harder. Imagine this scenario: You create the obvious route through the level to introduce a beginner to each mechanic you want to teach them. Then you add sneaky little routes / firing angles for the best players to use in a speed run. Then you notice you’ve broken the original route by doing this. Trying to juggle these different routes through a single map requires a lot more up front planning, and even then a whole lot of tweaking and playtesting. We all want to create that perfect Mario Raceway (Mario Kart 64) with its hard to achieve wall jump shortcut, or going back further, plotting the exact path through Green Hill Zone 1 (Sonic the Hedgehog) to try to get that elusive 27 second run. I’m not saying we’re in the same league as Miyamoto-san, Naka-san or Yasuhara-san, but hey, why not shoot for the moon.
Each weapon will have its own single-map tutorial, where only that weapon is available and the player must destroy a number of targets, set up in such a way as to introduce the player to the specific firing mechanism and features of that weapon. As soon as a tutorial starts, a timer will start, and it’s this that will be the motivation for the challenge. Medals will be awarded for completing a tutorial map under set threshold times, and we might also add in the best times of Ruffian staff (QA will probably win all of these as usual) as a further target to beat.
As a starting point, some general guidelines were set to standardize the tutorials. Without these, given there are two of us working on them, we would run the risk of creating a mish-mash of different things, with little commonality between them. The initial plan was:
- Best times to complete should be under 5 seconds (for the elite players)
- No longer than 60 seconds to complete for the least skilled players
- Shots should teach the player the different mechanics of each weapon. Even the easy ones
- One map for each weapon
- Try to create ‘red herring’ routes to coax players away from the fastest possible route
- Perfect route should be clever enough to make players think they’ve broken the level and beaten the designers
Once we get into creating levels for the more ‘exotic’ weapons, these guidelines may need relaxed slightly, but for now this is our plan of attack.
King of the world baby!
Killing each other has been the main pastime over the last few months in the Ruffibunker (see a photo from a previous blog to understand why it’s affectionately called that), however I’m starting to see a shift towards high score bragging rights as we add each of these tutorials. Shouts of 6.3 seconds, followed by retorts of 6.2 are now fairly common throughout the day, then someone finds a new approach and suddenly its 5.4! After a while of this, if the designer of that level is currently not the best at it, tiny modifications are made to invalidate all times for that map. A metaphorical “fuck this shit” table flipping moment. Naming no names though.
<cough> Dave </cough>
At the moment, the signs are good that this tutorial / challenge mode can provide a good dose of fun away from the main multiplayer aspect of Fragmental.
I’ve just noticed I used the word tutorial 11 times in this article. That seems far too many. Damn, 12 now.
Something beginning with F
As Billy explained in an earlier post, Fragmental is the product of a new experiment here at Ruffian; a small, multidisciplinary team working on developing our own IP using a rapid prototyping process. On paper it was an awesome proposition, but from a code perspective it presented an interesting challenge. While traditionally the projects we’ve worked on in the studio have been larger in scope, they’ve also been accompanied by larger teams working on them. In practice, this meant that there were always enough engineers to provide enough support for the art, animation and design teams to function efficiently. The question we now faced was what technology could we utilise to ensure our work flow remained as efficient with the move to a smaller scale team?
Over the last number of years we’ve worked with a variety of engines across previous projects, from our own internal tech which powered Crackdown 2 to more established third party engines such as CryEngine and, more recently, Unity. While these engines offered much of what we were looking for, they still required significant code support for each of the other disciplines to get their content into the game. In short, they weren’t what we were looking for this time around.
Powered by Unreal Engine
With some of the team having worked with the latest iteration of Epic’s engine previously on both personal projects and as part of some external pitch work, evaluation was completed swiftly. From full source access and multi-platform support to its powerful Editor and Blueprint system, it was felt that it would be perfect for what we were attempting with Fragmental. The Blueprint system in particular was flagged as something which had the potential to really free up the designers to try out new ideas without requiring much in the way of code support. With the decision made, a secondary objective of sorts was also soon set, just how much of the game can we build from Blueprints? The answer, as it turns out, was quite a lot.
The approach taken for the initial prototype was simple. On the code side, we pulled in various assets from the UE4 Third Person Example, grabbed the Character from the Shooter Example, tweaked movement to allow for our top down perspective and then hacked in support for four players. Over on the design side, Dave set about putting together a test level with a fixed camera over the arena so we could start testing basic gameplay mechanics. Looking back through the Perforce logs, it took thirteen check-ins before a single code file was added to the project. Not a bad start.
For those of you wondering what the first code file added was for, well if you’ve taken one look at our trailer or checked out the Steam Greenlight page during our recent campaign, you may be able to make a fairly educated guess. Yep, weapons.
The Simple Art of Murder
Once we had multiple characters running around a level, the next step was to enable them to murder each other. Obviously. The goal with our weapons system at the time was, to quote Barry – former Ruffian Technical Director – make it modular enough that a designer can create a gun which can fire anything, even chairs if he wants to, with no requirement for code support.
I won’t go too deep into the technical side of the project just yet but, in the context of our above goal, the weapons system worked as follows. The base weapon class was written in C++ and contained the various meshes used to render the object in-game, base functions to control equipping, firing and swapping out the weapon and a variety of structures to hold projectile and gun configuration data. This data would be exposed in the Editor for the designers to tinker with while the base functionality of the weapon was made accessible to Blueprint so that it could be callable via a weapon reference in other assets such as the Character.
The general idea behind this approach was that this base weapon could then be inherited from by the designers to create new weapons and projectile combinations with ease via Data-Only Blueprints. The end result looked a little something like this.
Part of the layout of the Assault Rifle Blueprint
Once the conventional weapons such as the pistol, shotgun and machine gun were in-game, the design and art team went to work creating new firearms of varying levels of destruction. More conventional weapons such as Rocket Launchers and Sniper Rifles soon followed and as the teams got to grips with the Blueprint system, more interesting creations such as the Disc Gun and Repulsor appeared. When code support was needed for iterations on existing designs such as a Homing Rocket Launcher, we were then able to jump in and quickly add the required functionality with ease. The system was working!
The Camping Grounds
As some of the design team worked on expanding and balancing our arsenal of weapons, others started work on a variety of new maps for the game. Watching how they evolved proved to be an interesting example of what can be achieved as Unreal’s Blueprint system is mastered. While the first few maps were largely static affairs with designs concentrating on varying flows to encourage different play styles, as soon as the team started playing with Level Blueprints things started to change dramatically.
With a little help from code, simple moving platforms transformed once static arenas into dynamic battlegrounds where spatial awareness became as much of a necessity as quick reflexes. Falling platforms were used to create frenetically paced homages to a variety of 80s arcade platformers and ultimately, the birth of the well-received Survival map types. Even the falling death spheres that Steve spoke about in a previous article have been re-purposed into massive rolling boulders which dwarf the player and provide additional environmental obstacles in larger scale Thunderdome-esque arenas.
Your Blueprints are bad and you should feel bad
Now, while this burst of creativity on the level design side may sound great, it did come with one rather notable caveat. As the Blueprints found in both Actors and Levels became more elaborate, their new-found complexity began to require more traditional coding principles be introduced in order to ensure they were not only more maintainable but that they also didn’t negatively affect performance. In addition to this, while the Level Blueprints allowed easy access to every Actor in the level, it also meant that any functionality implemented in them was unique to that level. This, obviously, wasn’t ideal in a game which was to feature around sixty levels.
These issues were solved by simply sitting down with the designers and showing them more appropriate ways of implementing what they had been doing previously. Chunks of functionality which required reuse led to the concept of Functions being introduced, inter-Blueprint communication required an understanding of Event Handling and liberal use of per-frame Dynamic Instanced Material creation led to equally liberal use of murderous glares from certain coders. Finally, in order to promote reuse of functionality across levels, we began to move the relevant contents of some Level Blueprints into the Actors themselves.
This was one of the better ones, spot the problem
Beyond the Support Class
Of course, while providing support for the rest of the team continues to be an incredibly important part of our role on the project, the freedom Unreal has given the content team has meant we have plenty of time to work on other core game features. For instance, the fast level switching required in a game where rounds can last less than 10 seconds required the use of a fairly robust level streaming system, the mesh fragmentation which makes up part of Fragmental’s unique look needed to be implemented across a number of areas both in code and in Blueprint and the dynamic music scene which gives our levels that vibrancy needed to be completely written from scratch along with a custom asset type and Editor Module.
In terms of gameplay work, the feel of both the character movement and weapon handling is extremely important to us with Fragmental so we’ve spent a lot of time ensuring they felt just right. Our animation set-up has continued to improve with both new melee attacks and stun effects being added based on feedback from play-testing and the remainder of the character poses have recently gone in for the respective weapon types adding that level of polish to the look of the character that’s always nice to see when you get out of the prototype stage.
There is unfortunately one major exception to all of this talk about the positives of Unreal, its Blueprint system and how it has lightened the code load – Networking. Duncan – Ruffian Tech Director – has been looking into this rather substantial task and has found the process so far, rather bumpy to say the least. The process and complications encountered merit at least one blog post to cover in any form of reasonable detail, so stay tuned for that in the not so distant future.
As for me, I think I’ve rambled enough for now. Future blog posts from the code team should hopefully deal with more concise technical topics like those mentioned above, but hopefully this post gave you a rough idea of how the project came together from the perspective of the code team.
Fragmental is a big deal at Ruffian, the mentality here is very much “If we do it, we do it right”, and as such I was brought on board a little over a week ago as a Junior Programmer to help expand the code side of the prototype team. Now this is a really big deal for me, as not only is this my first job in the games industry but my first job ever, probably quite understandably I was a fair bit nervous, and not really sure what to expect. I’d been working towards getting into the games industry for some time, doing my degree in games technology at Abertay, and had heard about all kinds of games studios, from lackadaisical beanbag developers to cold, quiet corporate code factories. As it always is for these things, the reality is somewhere in between.
The office is pretty much as you’d expect, big black towers for development PCs, with dual screen setups common to a lot of work places these days, but you start to notice the differences pretty quickly. Every desk has a 360 gamepad hooked up, various games consoles are set up around the room for various purposes, and there are even a few unplugged arcade machines sitting just next to the staff kitchen. My tour around the office doesn’t take too long, I’m shown where my desk is – I have a desk! A fact that surprised me with how chuffed I felt about it – and taken around the office to be introduced to the various people working in the studio. An essential part of this tour included being shown where the snacks and drinks are kept, both of which are regularly stocked to facilitate smooth game development. While I did spend a fair chunk of my first day playing Fragmental with the team – nothing like some competitive multiplayer to get you started – Ruffian is still a business, we have team meetings, I have office hours to keep, company policy to read up on, but this is all necessary for running a successful studio and none of it bothers me.
Working at Ruffian
To the code! Sort of…
With introductions out of the way I was given my first task, Sudden Death. This was meant as a gentle introduction, no firm deadline, no direct supervision, just ask if I have questions, don’t break anything. All I needed to do was create a HUD element that would pop up after a certain amount of time, announcing Sudden Death had begun and then sweep crackling death walls in from the edges of the level, to force the players towards the centre and their ultimate demise. My background is mainly in using C++ to code and while UE4 does use C++ for development, I’d be starting off using Blueprint, UE4’s visual coding system in which the majority of Fragmental has been built. This led to a couple of awkward situations early on, where I was writing down how I’d implement something as if I were going to code it in C++, and then translating it into Blueprint – achieved with liberal use of both the Blueprint documentation and Google. With a few key questions to the right people and banging my head against the crossbeam weapon code until I understood it enough to use, I’d made a Deathbeam! It moved! It crackled! It didn’t actually kill anyone… oh.
Deathbeam Walls in action
Fortunately this was easily fixed with a big old invisible box of instant death, that made sure the players wouldn’t escape its effects even on the multi-tiered levels. Then just add in a quick tool to help the designers easily tweak it for each level and it’s time to nervously tell the Creative Director I was done. The response of “Fuck off! Really? We expected that to take you longer” was quite unexpected but very reassuring, getting the task done in a day was good news. Having finished my first task and not completely broken anything, I was soon given a list from the backlog to plug away at. More HUD elements to help track who was in the lead or on a kill streak, the ability to create a pulse effect at the player’s location so people could keep better track of themselves, and finally a nice little animation for weapon name tags, to announce when a player picked one up. That last one caused me a little more trouble than the others.
HUD Elements actually in use!
Breaking the game a little
Being young and a bit inexperienced, I had foolishly only tested the weapon pickup feature with Player 1, where admittedly it worked perfectly, things didn’t work quite so well for Players 2 to 4. I’d been brought along to the Games Are For Everyone event in Edinburgh to help show off the game, a fantastic night with some really interesting games on show alongside Fragmental. While watching people play though, I noticed that the weapon tags weren’t showing up for certain players sometimes, I thought this was strange and made a note of it, I also noticed that the pickup animations I’d put in weren’t playing for any of the players so I endeavoured to take a look at that the next day. After a little bit of experimentation, I found out that both issues were related and definitely my fault. Fortunately because they were my fault, I quickly removed the offending code, in Blueprint this is sometimes as simple as unhooking a couple of nodes, and started working on a fix. Apparently no one else had noticed the bug, but they seemed happy with my response of pull it out until it’s fixed. It didn’t take me too long to get it all working properly, and the fix was back in the build by the end of the next day.
Game Modes and Beyond
Next up I’ll be working on some new game modes for Fragmental, to build some extra choices on top of the current Deathmatch/Team Deathmatch modes. This is a little more involved than what I’ve done so far, but I’m looking forward to the challenge. If you’re one of the people planning to get your hands on Fragmental, you’ll almost certainly be playing them, that’s a pretty exciting thought for me atleast. So in my first week and a half I’ve made some things unexpectedly quickly, put some things in the game that didn’t break, broken the game a little bit but managed to fix it, and, I think most importantly, learned where the snacks are. This whole making video games for a living lark seems to be going pretty well.
HUD is a complicated subject in Fragmental. When you’re playing the game, your focus is either on your character or on your opponents, there’s a lot to take in and a split second distraction from the HUD, or a quick glance away from the action to check your weapon could be the difference between winning or losing. It’s a strange thing to be working on an area of the game that you actually pay very little attention to while playing the game. I think in general HUD should be pretty unintrusive, but it’s essential with Fragmental.
We held some playtests at the studio a few weeks back with some students from Abertay, and the feedback was invaluable. Some of the points raised we were aware of beforehand, but it’s always good to have things confirmed. In certain areas, like the HUD, the feedback was almost unanimous in picking out a few core issues, mainly with not knowing what weapon you were picking up and when you were out of ammo. Pretty important stuff in a game that’s all about the weapons.
The design of the weapons was covered in a previous post, but on top of the actual design of the weapon, we also decided to add ammo bars below the characters. This made it immediately obvious how much ammo you had, and when you were empty, all conveniently placed in an area where your focus was anyway. It also changed gameplay slightly but I think for the better. We were worried it might cause people to hang back a little, and it does provide stand-offs in certain situations when you’re cornered, and you only have a couple bullets left, but if anything it’s just added more variation to the gameplay. You’re still sometimes too focused on other things to notice, but more often than not one of the player’s who are dead and now simply spectating will shout ”Quick! He’s empty!!!” causing you to barrel in all guns blazing like Rambo, only to get hit right in the coupon with their weapon, which stuns your character and knocks their weapon out of their hand. Then all you can do is watch as your opponent picks up the weapon you just dropped and kills you with your own gun. Obviously this is an entirely hypothetical situation and has never, ever actually happened to me…
Check Your Corners? No Need
So it does it’s job and doesn’t take you out of the game for a second. This is really the cornerstone of any HUD we have. If it’s gameplay related then it really needs to centred around the characters, not off in the corners. We’ll have things like player names – we’re going for a 3 letter arcade throwback here – but these aren’t things you desperately need to know in the heat of battle. We also have the current weapon but this is as much for spectators as it is for players – it’s surprisingly fun to watch this game too, like seeing someone shoot the disc gun, only to have it ricochet three times and come back, and hit them square in the face. You rarely have time to glance at the corners, and you should ideally be able to pick out what weapon your opponents have by their silhouette, or perhaps the big electric beam of death that’s now headed your way!
Picking up Modifiers in game is something that currently needs work. At the moment it’s not always immediately obvious that a Modifier has been picked up and activated, and by the time you’ve realised it has, it’s probably too late. Some of them are relatively easy to identify as soon as they’re picked up; Shields give you a big glowing sphere around you, Motion Sickness rotates the map and Infinite ammo will change your ammo bar to show an infinity sign within it. These all have visual signifiers that tell you what modifier is active without having to look at some HUD at the top of the screen, but on top of that they are positive or fairly passive Modifiers, so they carry no immediate threat. I think we should give this visual treatment to all of the Modifiers. We have a Modifier which reduces friction between the characters and the floor, which creates a feeling of moving on ice, so maybe we should make the arenas look a bit frosty when this is active. Again, nobody looks at the HUD so the more we can do in the game world, the better.
Retro Futuristic Fonts
Fonts are another thing that’s been a bit of a challenge. Fragmental’s art style draws from a lot of retro futuristic 80s style artwork. We’re not entirely trying to emulate that era, but there’s a lot of cool reference that fits with our colourful, vibrant visuals and audio reactive backgrounds. There’s so much stuff, which has quite a simple futuristic font combined with rough brush script. Also, a lot of it is pretty chrometastic, so I thought this could be a good avenue to explore. I originally had a brush script font for the weapons, and while it looked cool, it just wasn’t readable at times. The HUD font choice has been through a fair few iterations, sometimes you think you’ve found the perfect font and one letter throws it completely off. It’s still a bit rough round the edges, but I think we’re on the right track.
At the moment I’m working on the end of round screens, I’d like them to loosely resemble bars on a graphic equalizer, where each bar represents one kill. Here’s one I made earlier! You’ll notice I let Dave win in the mockup…. I thought it was only fair seeing as I don’t usually let him have that chance when we play.
Why have I opened with a screengrab from the Torture-porn – what a name for a genre! – series “Saw”?
The answer to that is that I’ve had to pretty much turn myself into the antagonist of the first few films, “Jigsaw”, in order to come up with enough variety for the survival levels in Fragmental. Actually, a much more accurate reference would be the film “Cube”, but that might be a bit obscure as it was a low budget indie film, and Saw has become a money making juggernaut. Plus I really wanted to start with that picture, so there. Aaaaanyway, the point of all that was that myself and Dave – who did the other half of the survival levels – needed to think of as many different / horrible / innovative / funny ways for players to be able to die as possible, while being mindful that the whole point was to be the last survivor standing.
Inspiration comes from the weirdest of places, and at totally random times. Personally, I find that a lot of inspiration for my levels comes from TV & films – who knew wasting so much time watching TV as a kid would turn out to be a good thing! Creating a level with just enough of a nod to existing media, can give a player that empowering feeling of “Ah, I see what you’ve done there, I know what you were thinking of when you did that”. To demonstrate, I’ll highlight a couple of my levels, and explain their genesis and development over time:
The Alien franchise is the best film franchise out there. You could argue for The Godfather, or Star Wars, or The Lord of the Rings, but you’d be wrong. For the younger ones reading this, don’t even go there with Harry Potter or Twilight…
<Spoiler warning…actually it came out in 1992, I think we’re a little past spoilers>
For this map, I was specifically thinking about the climactic scene of Alien3, where Ripley and the remaining convicts attempt to trap the Alien in the Foundry, pushing it into the smelting mould with an automated piston. This idea of a trap appealed to me, though in the film it was a very slow shunt. For Fragmental, it would make sense for this to be a high speed ram that would catapuly players off the map. To increase the frantic nature of the level, I also included small alcoves, like in the film, for players to jump into to avoid the piston. The translation from film inspiration to in-game level was pretty close, the only question being how to activate the moving parts. We had enough levels that were automated, so for this level it seemed worthwhile going a different route and letting the players activate it – also in keeping with events in the film. The final touch was allowing any player to activate the piston at any point, so buttons were added into each alcove, potentially one for each player.
The end result is a frantic dash and then you play a bit of a cat and mouse game with the other players as you decide whether or not to venture towards their little hiding place. There are no back walls on them, so you can punch them off the level if you get the timing right. Get it wrong and you’ll be slapped off the level by the massive piston. It’s very simple, but it’s a lot of fun to play.
The 80’s were a golden period for animation. At least they were if you wanted a vehicle to advertise your toy range, causing parents across the country to search for weeks before Christmas for the one shop in town that was rumoured to have that latest Transformers / He-man / Thundercats figure. I’m writing this from a male point of view only, as I refuse to type ‘Young Girls toys’ into google…
Trap door was different. An exceptionally British stop motion animation, based around a blue, ummm, thing, called Berk, who worked in the basement of his faceless master’s mansion. The titular trapdoor was set into the ground, for reasons that over the mists of time now escape me. Anyway, if it was ever opened, something good / bad / random would come out. For my Fragmental level, I liked the idea of a big trapdoor that would suddenly open, causing players to drop to their doom. However, on testing this everyone simply stuck to the sides of the level , rendering the trapdoor pretty useless. The simple solution here was to instead make the centre safe, and the edges the trapdoors, so the best players will maintain a central position in the arena. Kind of like Sumo.
This level is also great fun, but there’s slightly less focus on specific tactics in this one, it’s more about getting the timing right for landing your melee attack properly.
This is possibly the least obvious inspiration of the lot. D.A.R.Y.L was a 1985 – notice a pattern in my inspiration yet?! – film about a kid who was really an AI experiment, who, umm, actually just watch it or IMDB it or something. It’s like all films from that era, you can pretty much guess the ending about 10 minutes in. Long story short, in one scene Daryl plays Pole Position on an old Atari, getting faster and faster until it’s impossible for a normal human to play.
I wanted to make a very different level to the rest so far in Fragmental, along these lines. More recently, this has been done in the ‘Zone mode’ in the Wipeout series. Now, being totally honest here, I have no idea why I thought it would look funny if they were running around a vinyl record player. I just did, so that’s why the level ended up looking like it does. This is one of my most Marmite levels, some of the Fragmental team love it while the others groan every time it appears, but more importantly everyone we’ve shown it to in public loved it. Get in.
There are plenty more survival levels, inspired by things such as Pinball, Snooker, The Clangers, and The Rancor pit in Return of the Jedi, but I don’t want to show off everything too early!