Workshop Summary Recently Guerilla Tea teamed up with the National Deaf Children’s So...
There were several objectives we wished to achieve during the day. Primarily we wanted to show the group that game making can be for everyone, no matter your background or situation. We also aimed to introduce some of the core game development principles and procedures without the need for any prior knowledge.
The day started with a short registration, including the group receiving Guerilla Tea T-shirts, making each of them honorary members of Guerilla Tea for the day…
This was followed by an awesome introductory ‘warm-up’ game coordinated by the NDCS staff, involving quick reactions.
We then ran through what the day would involve with short introductory talks from ourselves and Abertay. Alex gave a light hearted introduction to what code is, what it does within game development, and how our favourite games are underpinned by maths. Matt introduced visual design in games and the role that artwork and artists can have in game development. The talks culminated in a great inspirational speech from Abertay Lecturer Ryan Locke about why we love games and how that love can translate to game-making and one day game development as a career, and the routes made possible through courses at Abertay University.
From here, we split the group into the children interested in programming and those more keen on the art side, then put together the coders and artists into small teams of three or four.
Before jumping into anything technical, we began the day’s development with an initial design session for all the teams. During the prior week, we had put together the bare bones of a top-down endless runner game, and the design section essentially involved each team filling out a worksheet allowing them to come up with themes for the various parts of the game. They had a chance to choose the setting, the type of player character, the enemies and a selection of power-ups (we had pre-defined the functionality).
This workshop was actually run in a slightly different fashion to our previous workshop. Naturally during the course of a day, there was only the time to create a single type of game – the top down endless runner – but we wanted each team to give it their own flavour and theme, so by the end of the day we’d end up with a series of games, rather than one single product. We’ve found both approaches work very well.
By the end of the design session there were a lot of different themes for the game, involving various settings and some creative ideas for characters and enemies.
The day was then divided into two development sessions separated by a lunch break.
With a creative vision established for each team, during session one the programmers moved to a separate room to work with PCs, while the artists remained to begin creating the art assets for the games on paper. The programmers essentially got a very basic introduction to Unity, involving the layout, prefabs, transforms and the creation of game objects. Towards the end of the session they started on some basic code. The artists worked on creating line drawings for each game asset, ticking off each item on a list as they progressed.
Ryan and Matt used the lunch break to scan in and crop all the images.
After lunch we began session two. The artists moved through to the computer room, where they began working with Adobe Illustrator to add colour and some more detail to the assets. Session two for the coders involved writing the bulk of the code for the game; essentially the slightly more complex areas which made the whole game come to life. The result was a top down infinite runner involving three lanes of movement. Players move a player character from lane to lane, avoiding obstacles coming down the lanes, while trying to collect power-up items such as extra lives. The player’s score is recorded as the distance travelled which is displayed on the game over screen.
Guerilla Tea along with the excellent staff from the NDCS overlooked and helped with both sessions, and by the end of the day, each team had a working game, complete with unique themes and their own artwork. The day finished with a short evaluation session, and the group got a chance to showcase their creations.
The Day’s Creations
We have compiled all the games created during the workshop into a single mobile application for both iOS and Android. There is also a web version.
To run the workshop smoothly we created various documents and worksheets to keep things on track and moving forward. These may be of interest, particularly if anyone is thinking of running a similar event at some point in the future. Find the documentation at the link below:
The main take-away for running a workshop with any group of young people is to put in the hours of preparation before the day itself. You absolutely must pre-design and build the skeleton of a game of your choice, with the caveat being it must be incredibly simple. Think endless runner, space invaders clone, breakout game, etc but in all honestly the endless runner has worked well for us. During the workshop you essentially re-build the game step-by-step from a code side. For art, drawing on paper and scanning in the images proved to be the best solution for ourselves, and was the most fun in general for the group taking part. We did however include the basics of Adobe Illustrator to colour the scanned images which also worked very well.
All in all, the day was a great success and everyone taking part thoroughly enjoyed a taster of game development. A huge thanks from Guerilla Tea to the National Deaf Children’s Society, and to Abertay University for hosting the event.
The Global Game Jam 2015 is over for another year and it’s genuinely been the most en...
The Global Game Jam 2015 is over for another year and it’s genuinely been the most enjoyable jam we’ve attended yet.
With the office equipment boxed up and moved temporarily to Abertay University, and the core dev team stocked up on a range of healthy snacks and caffeinated beverages, the 48 hour game making marathon began.
The theme of this game jam: “What do we do now?”
This opened up a lot of possibilities and we set about on our normal brainstorming process, although in the end we decided to do something a little different…
Instead of taking the theme and trying to fit a game concept around it, we decided to literally apply the theme to the process of building the game.
Firstly, Brian quickly hacked together a random word generator, primed with a long list of words established during the usual brainstorming session. Every two hours it produced a word telling us what we do now, so that’s the jam theme covered in a nutshell!
Art and code then set about building something which related to the word, and spent some time putting it all together into a coherent whole.
During the 48 hours, the words we had to work with were Nature, Klein Bottle, Window, Mountains, Misery, Cookie, Camera, Blue, Survival, Lever.
Admittedly, ‘nature’ was a good starting point, so we put together a lush environment, but after that it essentially it became a video game interpretation of dada…
We ended up with a random Klein Bottle…
A UniPig… The ability to ride a critter that’s a cross between a Unicorn and a Pig.
And a Mountain Launcher… Yes, a gun that shoots mountains!
And many other weird and wonderful things.
The reason this particular jam was so enjoyable was down to the process. Although we got a strange mash together of different objects and gameplay, the fact that every few hours there was a completely new problem to solve kept the team interested.
The game itself assumed the title ‘What have we done!’, and it’s something that could never really have been made if it’d been pre-planned in the normal way, even if we’d tried to go as crazy as possible with ideas.
It’s easily our most trippy experience to date, and with the Oculus it’s just a little insane…
The original post “Guerilla Tactics – Handling Unfamiliar Terrain – How to deal...
The original post “Guerilla Tactics – Handling Unfamiliar Terrain – How to deal with Clients” was written by Alex for a blog on MobileCamp Dresden. Take a look at the original article HERE.
So, let’s talk about clients. I know a lot of indie game devs frown at the very thought of working for hire. And let’s be honest here, if we could just do our own stuff without ever having to worry about how we pay next month’s rent or get food on the table, most of us wouldn’t even bother talking to someone outside the industry. But the reality is, we’re still running a business and we need to make money. And unless we’re producing the next Flappy Bird or whatever magical timesink is currenly floating on top of the app store charts, we need to have an eye on our revenue stream.
Now, I’m no expert, but we’ve been around for about 2.5 years now and worked with a whole bunch of different clients from a variety of industries. The most notable ones were DC Thomson and of course Cancer Research UK, with whom we developed the hugely successfull Play to Cure: Genes in Space – the world’s first mobile game that actively helps with finding a cure for cancer (seriously, how epic is that?!). But all of that still doesn’t make us the ultimate authority in the field of B2B relations, so don’t take everything I’m writing here as gospel. It’s just how we do things at Guerilla Tea because we found they work for us, and our clients.
Now, with that said, let’s get to the question. How do we deal with clients that don’t have a games background but want to develop a game? (Note: most of this is applicable to pretty much any client regardless)
1. Know the territory!
This is probably the most important part when working with a new client. Do your homework! It’s a bit like a job application; the better you know who and what you’re dealing with, the easier the whole process will be and the less friction will occur once you actually start working on the project.
The first thing we did when putting together the pitch for Genes in Space was researching the other companies involved, their experience, past projects and so on. For example, we knew CRUK had already sucessfully launched a serious game on the web called Cell Slider together with Zooniverse (of Galaxy Zoo fame), so we knew they had some experience working with external developers and had people with the technical background to understand the implications of running a backend system for several hundred thousand users. This was great for us since it allowed us to be more technical and therefore precise when writing the pitch. If your client doesn’t have a technical background, it takes a lot more effort to explain what and why you’re doing things, so be careful and make sure you adjust your language appropriately (and *never* try to hide knowledge gaps behind tech lingo)!
Maybe even more important than researching your client is doing the research for the project itself. What is it? Why do they want it? What and who’s problem does it solve? How? For Genes in Space, this involved me digging through every academic research paper on BAF Data, detection of Copy Number Variations and related subjects that I could get my hands on. I didn’t become a Geneticist overnight, but at least I got a good enough understanding to be confident about the project requirements. As a side note here, don’t be afraid of researching subjects that you don’t have previous experience in. My knowledge on genetics before that was basically 7th grade biology and watching Jurassic Park, but by constant cross referencing and a lot of help from Wikipedia I still managed to get a decent enough understanding of the subject. You don’t need to know everything about it – that’s your client’s job – you just want to know enough to communicate effectively and make sure you understand what it is you’re supposed to be doing.
At the end of the day, this will keep both you and your client happy because you will have a lot less misunderstandings that cost time and money to resolve. The more you know about your client and the subject, the easier it is for both parties to find and realise a common vision!
2. Control communication!
Keeping clients in the loop is important. Keeping clients that don’t know about games development in the loop is a lot more important. Look at it from their perspective: they just shelled out a lot of money to a company they never worked with to build a product they don’t fully understand. Of course they are nervous, so the better you keep them informed about the project, the happier they will be.
We acomplish this in multiple ways. The first one is to have regular conferences with the client (usually weekly). If possible do face to face meetings, but if the distance is too large, Skype and Google hangouts are two viable options we use regularly for that purpose. The more often you communicate directly, the easier it will be for both of you to spot problems and address them before the project veers off track.
You also want to give your clients at least some access to your internal scheduling tools. Trello and Asana are really good for that, but if your tool of choice doesn’t support this behaviour, an up to date spreadsheet on Google docs will do the job as well (you should still get a better tool though, because yours is obviously crap). This will reduce unnecessary communication overheads because everyone involved knows what you’re currently working on and when a certain feature is supposed to be implemented.
Finally, having an iterative development methodology works incredibly well with that. This way your client always has the latest stable version of the game for testing, and necessary changes can be fit into the schedule with very little friction. You don’t have to use any of the heavily formalized methodologies like SCRUM for that. We’re using our own homebrew mixture of agile and waterfall which gives us enough stability in terms of cost and time projections, but still allows us to act and react very flexible on changing requirements. Anything that gives your client enough input into the development process should work.
In addition to keeping up client communication, make sure you don’t forget to talk to the most important group of people: your target audience. Most of the time this will be your players, but it doesn’t have to be that way. For Genes in Space, our main audience were not the people who played the game but the researchers that had to use the analysed data. We therefore made sure to run any changes we made to the data analysis by them first to verify that it was still accurate enough. We also sent them regular samples of the data to see if we needed to improve anything. That’s not to say that we didn’t do regular playtesting sessions as well to make sure the game was fun and accessible, but those were not our main priority.
3. Hold your ground!
The last lesson we leant when dealing with clients was probably the most difficult one, but it’s absolutely crucial if you don’t want your project to turn into a nightmare of Lovecraftian proportions: you need to learn to say no. I know this is hard. It requires being somewhat confrontational and it can be incredibly scary because that clients money could be the only thing keeping your company from going belly up. But if you think that a client not getting the feature they wanted is bad news, wait till you see what happens when the deadline slips for the 3rd time because the project is choking from feature creep, you’re nine months late and your code has more bugs than a roadside motel bed because all those nifty little features were glued together by spit and good hopes, without any proper planning whatsoever. That is when you should be scared.
Now, I’m not saying you should just tell your client to bugger off when they have an idea for a new feature. But if it doesn’t fit into the schedule or would be too costly to implement or is just a generally bad idea, you’ve got to deal with that. Explain the situation. Look for compromises. Maybe you can get that new feature in if you remove another one that is less valuable. Maybe you can come up with something that is less costly but emulates almost the same functionality. In the worst case, tell them that you will have to adjust the schedule and costing of the project if they really want the feature in. Whatever you do, just don’t simply say “yes” because the client asked for it; that’s the express lift to developer hell. Stay focused on your goals. Keeping the project on time and on budget is infinitely more valuable for everyone involved in the end than a little disappointment every now and again.
Also, don’t just watch out for the client. Your team members are just as prone to come up with potentially damaging features. However, they are usually easier to deal with since they have a better understanding of the development process. When we were building Genes in Space, Charlie (our designer) had a lot of ideas that I’m sure would have made the game a lot more exciting to play. Making a game fun is his job after all. However, we needed to shoot a lot of them down because they would have meddled with the accuracy of the data analysis. For these cases, I recommend having one team member as a dedicated “guardian”. The job of the guardian is to make sure that whatever is proposed does not interfere with the main goal of the application; a bit like a vision keeper, but with a much narrower focus. Take the person with the best understanding of the project’s goals and give him the authority to veto every new feature if it violates these goals.
Now, as I said at the beginning, this is just the way we do things. It took us a while to get there, but for now it works pretty well – for us and our clients! However, we’re still prone to making mistakes at one point or the other, so if you use a different process that might help us or have a good idea that might improve the ones we have, we’re looking forward to hear about them. Maybe in a year or so I’ll write an update for this post to see what we’ve learnt in the meantime.