Game Design – Developing With A Team

(This is getting out of hand, I’ll have to put up the next one tomorrow! Sorry to those following this, I’ll endeavour to fix my bad timekeeping.)

Developing with a team is something that you will have to do at one point during your game making career. Thankfully, most courses have modules on this and will prepare you for the horrors and pitfalls of sticking to a schedule while also dealing with other people.

Currently we are making a game in unity in a group of 4. A simple project that draws upon past experience of most members. But there are many pitfalls you would not and could not predict. This weeks Game Design lesson is; Developing with a team and how to prevent yourself from getting arrested.

To give you an insight of how stressful it can be working in a team;

A friend of mine in another group in the same class as my unity group, has had: The animator tell him he has done no work for 7 weeks because other classes were more important, the programmer have to focus on other things due to a death in the family and the other designer disappear off the face of the earth and only leave a cryptic “I’m 300 miles away”.

In college, me and this friend worked with two other guys who, for most of the year, did not show up. It was only in the last week (And on the deadline day) that the programmer showed up to work.

Not the greatest horror stories but they are true and will happen to you. People will burn out, people will not care and people will not try.
(If you manage to get a team where everyone is passionate, hardworking and easy to work with. Send me an email, I’d love to come join.)

What you as the designer needs to do is make sure everyone is on track, in attendance and working. This can be as simple as just having a friendly chat with the team members when you get the chance. I’ve found that this tends to be the best way to keep a project moving forward. If you can, offer to buy lunch for the team if they make a lot of progress in a week or get some drinks. Like it or not, you’re a family and you should be as close as one.

To have a good development environment you should:

  • Talk often both about the project and other things.
  • Stay in contact, give constant updates.
  • Give reasons for absence and give warning if you can.
  • Hang out and have fun when you can.
  • Make sure you pull your own weight; be passionate about what you do or leave.

It’s not always possible to do this though as you may be stuck with assholes, wasters and unmovable visionaries.

To deal with these problems, I’ve got a few tips but no sure fire methods yet.

Assholes

These are the guys who want to make the game about a weed smoking sperm cell who fights AIDS for your first commercial product. Sure, it might be a good idea to some, but not for a commercial release.

  • Ditch them if you can.

If you can’t ditch them; You’re not the boss, your group is already too far in to cut people off, then;

  • Assign them things that can’t be ruined.

Code is usually a good place, code can’t really be ruined. If it does the right thing, it’s good enough. Though you might want to send someone through it with a comb, just in case there are any surprises.

  • Talk to them about the product

Before the rest, try talking to them. Most people understand what is okay and what isn’t once they know what is being made or aimed for. Give them the benefit of the doubt and try explain what the team is doing before relying on the other methods.

Wasters

Procrastinators and time wasters. They are the bane of a product. Even worse than the Assholes, Wasters don’t want to have any part of the product other than the payment at the end. They can often be ditched by talking to those with the power to do so. Though if this isn’t possible, i.e. In a university group. Then you can rely on;

  • Don’t ask, don’t tell

If they are happy to do nothing towards the project, don’t give them a part. When they start panicking at the end of the project as they realise they’ve wasted their time. You can decide what to do.

  • Give them the optional extras

If they need to put something down as theirs, give them the optional things. That way if they waste their time, you will still have a finished product at the end.

Unmovable Visionaries

You may never encounter one of these (You might be one yourself, get tested) but they are the worst to work with.

The most important part of developing with a team is collaboration. Everyone’s opinion and voice should be heard and taken into account. You may be worried about your vision warping to include elements you don’t want. That’s fine, keep that one in your personal pile and make it yourself OR hire a team to do it for you. Developing with people requires respect and the ability to bend your ideas to fit the project.

Unmovable visionaries do not understand this and will remain rooted on their idea even if its a bad one. There are ways of working with these people though.

  • Be careful with your wording, UVs can be very protective

Think of the UV’s idea as a bear cub, your job is to turn that cub into a dog without openly saying you’re changing it. A difficult feat to perform but one you will have to learn. This is also useful when talking with publishers.

  • Rely on democracy

At the end of the day, the group gets to decide. If one member says “Screw you guys, I’m goin home” and takes his idea off the table, lest it be criticised. So be it. Start fresh and let them pout. As many developers will tell you;

flexibility is key to success.

And lastly;

  • Stand your ground

This is difficult for some people to do and it shouldn’t be. Don’t be threatened by the Unmovable Visionary just because (s)he uses big words or is older than you. You’re in the same boat and staying quiet while they lead you further to sea is just going to make it harder to turn back when you need to.

—-

Developing with a team is great chance to meet people and network and it is definitely something everyone who wants to make games should do. Go to Game Jams by yourself and throw yourself into a team. Ask around on forums or even start a project and gather people together.

If anyone needs a writer and designer just give me a message. I’ve got five months off soon and I need something to do!

Previous                                   Next

Starting Development              Keeping the vision

Game Design – The High Concept

So we were put into our groups this week and handed a list of briefs to work on. Naturally, these were crap so we emailed the lecturer and proposed a 2D platformer made with Unity.

They said yes and we got underway with planning out our game. Well, those of us who attended the first meeting did.

Anyway.

At this stage in development we simply had the broad overview of what we intended to do, a 2D platformer, a decision that was easily reached as we had two designers, a programmer and an animator who hasn’t done much 3D modelling.

Then we discussed what languages we knew, c# and Javascript, which are both supported by Unity. Which also supports 2D graphics design.

With this in mind, we began discussing ideas for a 2D game and things we would like to see in a game like this. This is called The High Concept. We decided upon a stealth focus where the player is young, we also wanted to do a Sci-Fi theme as a friend of mine had some ambient Sci-Fi tracks and we had discussed making a Sci-Fi game with his music as the soundtrack.

This is actually how games are made, a bunch of people sit around and say “It’d be cool if you played as an alien.” So don’t be afraid that you don’t have training or qualifications. Get some friends together, discuss what you want to make and make it. (Though you may want to aim small and simple at first)

Tips

For those just starting in a team with little to no knowledge of programming, use programs like Gamemaker Studio and RPG Maker. These will give you a good grasp of how to make games without requiring too much prior knowledge.

Game Maker Studio
RPG Maker
Construct 2

Don’t be afraid to fail/suck, your first games will be terrible but you will learn a lot from these early attempts.

Keep everything, have multiple backups and never throw anything away.

Next week

Gantt Charts and Project Planning

University Update

So we’ve started the new trimester and it seems we have actually been tasked with creating some games. I’m as shocked as you are. Real live games in a game development course!

So it seems they have managed to reel me back in just as I was considering dropping the course. What this means for this blog and you awesome people who follow me is two new games (Technically three but the third was meant to be for last trimester).

One mobile focused game and one 2D game powered by Unity.

I will update with more information on both as I get it but if you are interested in the process of creating a game in a team then comment or like this post and I’ll update weekly what we have to do and why.

Phoenix Break

As part of the Javascript and HTML5 module we have been working on we have made a breakout clone called Phoenix Break.

In Phoenix Break you play as a phoenix trying to catch and kill a group of soldiers who have stolen your egg. Why? Fucked if we know, we’re too busy trying to code the damn thing. Honestly, Javascript is the worst language I have ever used and the way we have been taught it is insulting at best. A direct quote from the lecturer was;
“And that’s why people hate Javascript. You could use these programs instead.”

So yeah, here’s a screenshot from the game. No ball code yet though.

PhoenixBreak

Those who play

After attending Games West (A talk held at my university where some industry professionals talked to us about different aspects of the industry) I have decided to make my own pen and paper RPG.

The idea for the system and the core of the game is to explain or remove the tropes that seperate game from story in typical pen and paper (pnp) games.

Those who play seeks to remove this by involving the players as forces in the game, characters seek these forces out in order to gain power, earn fame or get revenge.

I will post the first draft here when it is completed and if it gets decent reception then I will work on getting proper art for the book and see about making physical copies!

Signing off on Salvager:Outlaw

So we are pretty much finished with the Game Design module so it is time for Salvager: Outlaw to go on the shelf. Heck, I might actually return to this idea in the future and attempt to make it.

But for now, that’s it. 

That isn’t to say that the blog is finished though. We’ve started work on a html game that I’ll be documenting in the following days.

Thank you to everyone who has been following and I hope you continue to follow.

Recap on Game Design Class

When I first looked at the content for this module I got quite excited to see that we would be learning about elements of game design such as Cognitive Flow, Balancing and the concept of fun. Three elements that are difficult to learn and apparently were too difficult to really discuss as the lectures for these topics were kept to half an hour at most which was disappointing. 

I had hoped that my time in this class would teach me a lot about game design that I didn’t already know or at least have a decent understanding of, but that didn’t happen.

All in all, this class was exactly the same as the one I did in the HNC but this time with a pitch to a panel of publishers. Which unfortunately we have been placed in week 10 because our email apparently never made it through.

So I’m quite disappointed about this class and hope that next trimester will be better.

Salvager:Outlaw Update

Sorry for the long gap between posts, it has been a while since we’ve had anything new worth showing.

But now we do!

Over the past few weeks we’ve just been polishing up things, reworking ideas, making some 3D models for the pitch and working on the pitch.

So here are some things we’ve been working on.Image

(Cover for the game by me)

 

Image

 

(UTA Turret by Fraser Gillespie http://www.frasernat20.blogspot.co.uk)

We’ll be pitching the game in a fortnight so hopefully all goes well and we pass.

 

Recap on Gamehack

(I slept for 18 hours, so yeah, go me. Also my computer broke for a while. This is the earliest I’ve had to write this)

So the gamehack at Dundee went terribly for us as a team as we encountered a bug that defied all coding logic and, collectively, cost us seven hours and all of our patience. 
This led to the team’s only programmer going to bed for the rest of the jam and the rest of us racking our brains over it. 

It was a disappointment to say the least and a major kick to the motivation to be honest. After two attempts at this game I’m not going to come back to it until some time in the future when I can have forgotten about this.

Positive note from the experience though. I have felt the experience of crunch time in relation to working in a group. So it has been a great insight into the future and I can be more prepared now.

And after two days I can say honestly that is has galvanised me to try harder and to get better at all aspects of games design. Because after Saturday night, I don’t want to ever be in a situation like that again.

Image

(We left the game as a cloud simulator).