Rapid prototyping for mobile games development

[Music] [Music] okay so thank you for coming to my talk today on techniques for efficient rapid prototyping my name is Jack Berfield I'm a games programmer for mag interactive down in Brighton but I've actually only been working at mag for a couple of weeks now and beforehand I was working for fat fish games where for the past sort of year or so we've been using rapid prototyping to maximize our efficiency and minimize our risk when creating new projects so what do I mean when I say rapid prototyping obviously prototyping in sort of a word gets used quite a lot but in the case of this talk what I'm talking about is creating a

sort of fully functional game in as short amount of time as possible or in the case of us a fat fish games it wasn't done sort of start to finish start to publish it in just five days it's about focusing on a single sort of game mechanic and building the whole game sort of around that and it's about doing this a lot it's about doing this sort of as many times as possible throwing lots and lots of apps onto the App Store and seeing what sort of sticks [Applause] so why would you want to do that well while I was working at fat fish we created a game called tiny striker world football and it did really well and it was really well received and we were really happy with it but the trouble was that we spent sort of a year on over a year even developing it and all that time we had no real idea whether or not people were going to like it whether or not people would enjoy this sort of base gameplay mechanic and it could have been that we released the game and they didn't like that and you know who would

have sort of wasted a years development time and that's obviously a really bad thing to do so most we're sort of rapid prototyping comes in is that it because it takes such a short amount of time to develop it doesn't matter if the game idea isn't relish and yeah it also sort of gives you a chance to open up a more creative freedom in your company so you know anyone can now sort of pitch an idea see it get sort of built and published even just because again it takes such a short amount of development time you can sort of take these risks with these little projects so now I sort of talk about what rapid prototyping is and why you might want to do it we can go on to sort of a few tips and techniques if you want to try it yourself so first things first is obviously you need to think of a few ideas and the golden rule here is obviously keep it simple you know you're not going to be making this sort of

amazing game that you've been planning on making your entire life you just don't have time to do that you want at least as I say sort of focusing on a really sort of small game mechanic maybe maybe one or two mechanics but you know as I say this real sort of simple ideas you want imagine the game player not the graphics so it can be really tempting when you're coming up with these ideas to say oh I'm gonna I'm gonna make some sort of amazing sort of spaceship game or something like that and you kind of want to avoid that well you want to be looking to do is think about your gameplay in the form of just sort of basic shapes some shapes and colors squares and triangles and that sort of thing because it means you can focus on whether or not your gameplay mechanic is gonna be sort of fun and after that you know once you've sort of released your prototype and people like it you can take it back and then improve the sort of graphical quality of it that's not to say the graphics aren't sort of important while making your prototypes and I'm gonna move on to that a little bit later in the presentation estimate the development time as I say you've

only got sort of five days and that's gotta be include testing it's got include publishing it's going to include some of a chance for anything to go horribly horribly wrong so think about your game think about how feasible it is to get that done in five days if you're not sort of a programming yourself you know have a chat with your programmer see if he thinks it's going to be feasible or not and then yeah just sort of go from there I'll get with someone this is something that we found was actually really useful if you if you've once you've come up with your idea find someone and sit down them tell them your idea and sort of us in the sort of pick holes in it and find problems with it because it's it's better to find problems with you right there at this stage then obviously three days in development when it's going to be sort of causing a massive problem so it's sort of like debugging your game before you've even written any code [Applause] don't scrap ideas you're willing to put them aside so you've thought of an idea and maybe it's gonna take too long to make maybe it just doesn't work as a

full sort of game loop whatever the case may be it's important to try to not panic and sort of try to mutate your game idea into something that will work you know under pressure as such it's a your end up with sort of a much weaker idea than if you sort of take that that original idea put it aside and allow it to sort of inspire you for future stronger fuller ideas so once we've got a few ideas a few concepts you want to pop them on a list so we used just Google sheets for this meant that everyone can sort of comment and add ideas sort of at their leisure and when you pop the ideas on a list trying to make sure that you're sort of being as descriptive as possible you really want people to be able to understand your prototype just by sort of looking at it ideally these games should be so simple that it doesn't you know it's not gonna take a massive amount of text and be sure sort of linked to sort of pictures and then even sort of other games that will help explain to someone who doesn't

know your idea exactly what you want to do once you've got those sort of things those ideas on a list you need to sort of rate them by how sort of feasible that's going to be to make them in five days and just how much you actually like the idea we had about three people giving future ideas not to ten rating and then obviously the highest rating ones got it got sort of made first and the sort of lower ones had a bit more chance to be thought about and improved upon and so they they became better ideas and then moved up the list and got worked on and it's another thing to watch out for when you're sort of working through your list of prototypes and you come up with a new idea it can be really tempting to be sort of like oh my god I've got I've got the best idea ever how huge the scrap absolutely everything we're doing and get to work straightaway on this new idea obviously you want to sort of avoid that you want to put that idea on the list you want to say argue with someone about it you know go through the whole steps that you do for

all your ideas because you might find that happened to us a couple of times that you jump on this new idea that you've had that you're really excited about Andy and it doesn't work it's dead it hasn't been thought about enough so before you actually get started building your prototypes something we had a fat fish which was really handy was a base project and this is essentially like a template from which all your prototypes will be built and it contains things that will save you time things that you find yourself repeating every time you start making a prototype a couple examples of things that we had in our in our base project of fat fish was a titled gameplay and game over screens so all of our prototypes it turned out were essentially just these three six three screens so obviously title screen with a high score on it gameplay screen where the actual gameplay happens and then a game over screen again with probably a high score in it and they would just loop round so we put these enough in our base project and that way we didn't have to spend a little bit of time every time we started a new prototype remaking

leaks we had a loads of different scripts and classes and things in our base project but a couple of things that sort of seemed obvious now but we didn't have straightaway a score manager so just something where a little class where we can you know manipulate the score save and load a high score we were doing this every time we made a prototype and it was taking you know not the massive amount of time but some time and you really want to avoid wasting any time at all a pooling class so yeah an object pooling class like it was good that it was there because we would have made the game without it we wouldn't bother making a sort of object pooling system every time we make these prototypes because as I say we're doing this as quickly as possible so having one there to use meant that it got used and meant that our game was more efficient basic graphics and sprites so as I said earlier you want to be thinking about your games as sort of squares and triangles and circles so having these squares and circles and thing two hand means that your developers can

just sort of grab them get started straight away and and they were just save them time early on some of our games didn't consist of anything more than circles and squares and colors so once you've actually started developing a couple of things to think about one is that ideally you want to be testing as often as you can so whenever you come up with a new gameplay mechanic or a new feature you want to be building out and getting that on a device and getting that in the hands of someone who can try it out obviously building takes a lot of time so you know don't go crazy with it you know aim for sort of one or two builds a day it's certainly whatever you do don't you know sort of work on your prototype all week and then on the last day builder on device and try it out because you'll find some problems you know you're bound to find problems and you'll have no time left to fix them well it's this was a really handy thing we had it's just a little system that could grab data down from from Google

sheets and then minute you know sort of adjust the gameplay without having to do a bill that sort of live grab two variables down so if we wanted to adjust the speed of an enemy or the amount of score that something gave you we could just adjust a value on the online on this Google sheet and it would instantly update the game and we could get a really good sort of game feel really quickly and really easily and we obviously with any project you want to watch out for sort of feature creep if you find that you do want to put a new feature in your game you think you can then you yeah obviously think about it again in sort of terms of development time are you gonna be able to fit this in in that five days sort of time limit and if not leave it you don't need it you can put it in if the base game is successful you can put that in later and again sort of similar for when you're coming up with your ideas when you're working on them you might find three days in development oh no this isn't gonna this isn't gonna fly this isn't going to work at that point again try

not to panic try not to you take the game into something new because at that point you're essentially making a new idea and that new idea should go through the whole sort of steps that I mentioned to make sure that it's solid enough to get worked on so mentioned earlier graphics are pretty important so I made a couple of mock-ups here of some examples of how graphics can be used the main problem is tutorials obviously tutorials can take a fair amount of development time to make and at the same time were these sort of little casual games a lot of users just won't won't look at them won't use them and if they don't use your tutorial and they try to play the game they don't understand they're not gonna like it they're not gonna open it up again and the apt go ultimately going to fail so graphics become really important and the idea is just to be as obvious as possible so start with like the title don't pop the balloon it's an instruction people get it I'm supposed to not pop a balloon

there's a picture of a balloon they're gonna sort of add it up add that up another really cool thing so rather than having like a start button on your on your main menu it get the user to do whatever action it is that consists the controls of the game in order to start the game so in this case the user will swipe to begin left or right and the balloon will move left to right and they've learned how to move the balloon in the first sort of second of gameplay and that's really all they need to know about the game another really useful thing is using like real world concepts and things that people can relate to to teach people about the mechanics of the game so in this case you're a balloon people understand that if a spiky thing touches a balloon it will pop people know that they're not supposed to pop the balloon people know how to move the balloon now to avoid the spiky things and they've kind of got the whole game sorting out coins are another good example of that is just obviously people know that getting money is a good thing so generally people will pick that up so once you're ready to sort of release

your prototype a couple of things aim for a single app store so don't try to take your prototype and put it on you know Google Play but at iTunes or whatever it's not necessary it's not really about getting these prototypes in the hands of as many people as possible it's more about getting whoever does get your game to come back to the game as often as possible and also don't try don't release one prototype on Google Play and another prototype on iTunes some pick an app store and go with that because it makes it easier to compare the performance of all of your apps so you don't either track a lot of analytics you basically just need to know when people are opening the game and how often they're opening the game and that way you can start putting forward some retention goals so these got to be pretty high when we were at fish we're looking for sort of around 60 to 7% day 1 retention about sort of 40% week 1 retention and

sort of 10 to 20 maybe 2 week 1 month for attention as I say you're looking for something really good you're not looking for any sort of ok games and talk about the monetizing so don't bother you know putting any in-app payments in don't putting any adverts in certainly don't charge for the app itself it's not really what this is about this is just throwing your game idea out there and seeing if people like it and if they do that's great take it grab it back you know put as many features in as you want spend as long and as long on it as you want and you know put all the lovely graphics and all that sort of stuff because you're now confident that the game that you're working on is something that people are really going to enjoy and that's pretty much what the rapid prototyping is all about so I think we have time for a couple of questions if anyone's going in yeah yeah so the question was in here

how well would this work for sort of more complex games is it just for sort of simple games and what I would say is probably the best idea is as far as your prototypes go if you're planning on making a more complex game test out parts of that complex game so make lots of little prototypes that will eventually consist all of the gameplay mechanics of your more complicated game so it's you know say it's a shooting sort of game have one prototype that's about the shooting one prototype that's about the movement or whatever the case may be and test out those little mechanics and that way you can kind of Lego brick together a more complicated idea later oh yeah why not we why not serve them why not three days so the question was there why did we decide to use five days that's it was sort of just a number we plucked really obviously five days just one working week so we decided to go with

that we could have gone with two weeks we could have gone with a shorter amount of time but the sort of golden rule would be don't change it between prototypes all your prototypes should probably be given you know the same time limit and that way you're not thinking well I did two weeks on this game and one week on that game but had I spent two weeks on that game would it have done better it makes it a little easier to compare if everything's sort of in the same timeframe and there's a lot of developers do do the same principle and I think two is quite common but like you say five is also common crap if he comes oh yeah from what like in average maybe so I didn't catch an average an average of the users that you get for this apps so how many uses yeah I mean it really depends if we had a little bit of money to spend on sort of advertising the prototype we would but it's as I say

it's not really about how many users you get in as I say it's more about getting whatever users do find your app to keep coming back but I so I'm not sure exactly what the sort of average number was as I say it's sort of vary quite quite a lot between different apps and it can be really effective if you only use something like Facebook Ads to find people who who are like the target audience you have in mind because then you can get couple of hundred players potentially for not very much money and that gives you lots of data you can then understand whether that worked and how it worked exactly [Music] [Music]