Sponsored By

Though on iterative design process on graduation project.

How i applied gdc talks to my thought process on an iterative design process for our graduation project in the level design and game design creation. “Adaptation when you have a “Over-Creative” team that has great ideas all the time”.

Antoine Fauville, Blogger

May 1, 2017

10 Min Read
Game Developer logo in a gray background | Game Developer

 

Though on iterative design process on “Research”.

 

 

How i applied gdc talks to my thought process on an iterative design process for our graduation project in the Level Design and Game Design creation. “Adapt when you have an “Over-Creative” team that has great ideas all the time”. I’m Antoine and I worked on the unity integration, programming and overall level design for Research, a graduation project at ESA - Saint Luc Art School, Brussels.

On a chronological side, we started the project with a simple pitch and no real Game Design thoughts, just some notes on the flow for general level design, what kind of interactions we would be in the game and some pitch on the story we wanted to tell.

At the beginning we had a lots of ideas but no real concept to start working with, I started to layout in a small scenery, the goal was to have a defined idea, to get the direction of the game for the team. It was a simple project with one type of interaction, but the main one, the one you would find everywhere in the game. I also tried to complete the “ 3 C. Rule”, Third person character with all of what it implies.

Once we were decided on the main prototype, we did a layout on paper for the main level design. At the beginning we had much more levels than we finally end up with. There were rough and stiff ideas. We didn’t know at the time how time consuming this way to work would be. Everyone had various ideas and wanted to tell something different in the general design of the game. Our team didn’t know the level of complexity for some content realisation. We didn't really know where we were going and with no concrete plan, we went deep in it straight, big mistake


Figure : Direct design process, create a scenery with all in it without testing.. big mistake...

 

One of my first big mistake back then was when I forgot that the others had different ideas and I had to start all over again my unity scene and this repeatedly every 2 or 3 weeks. Every time taking feedbacks and applying them on the build to create new iterations. I was forgetting the basic pitch of the game and with the team we were really getting far from the initial idea.

At first it was a third person exploration game with simple interaction and visual poetry with important narrative level design and content. And it became a “survival” third person exploration game with complex mini-games and puzzles. To finish with a return to the initial idea with puzzles and simple interaction for exploration but with a first person game.

  

Figure : left : Halfway in the project ( third person camera), right : third area of the game near the end of the year ( first person camera).

 

Talking about prototyping, as long as your game remains “not interesting”, the feedbacks will be negative (very subjective depending a lot on who you ask for feedbacks). They will always be about the bad sides of your game but then, when you get something good coming out, keep it, work on it, iterate on it, create different possibilities for it and with it.

Don’t change the game on one feedback, wait for many of those. Make a sheet with all the content you have in the game and assign the feedbacks to them, which can give you a better idea of what to do or what to work on. The more the feedbacks, the more interesting it would be to realise if this part of the content needs to be iterated

Being students, we had teachers surrounding us, they are people of experience that can usually give you good feedbacks but don’t forget that they are also very subjective. I guess it is the same with all type of work, paying attention to who is giving the feedback is very important. It could be bad or good depending on their interests and knowledge.

After few iterations of the game, restarting it over and over for 5 or 6 times, we were kind of lost, we didn’t know what direction to take, we had a rough idea of the game but no real starting point. So this was when we decided to apply what I called "iterative design on rough idea", we separated the game in different categories, one with the visuals, another one with the mechanics and a last one with a rough level design plan.

 

Figure : The technical scene of the demo before the January presentation.

Figure : The graphical scene of the demo before the January presentation.

 

With this we had different parts of the project that could be shown individually to get more feedbacks.

Once we were confident with a piece of content we would add it to the main scene of the game. It was a long process, and also we had to jump from the game to test it out then come back in the individual scenery. After a while we realised that each part of the game had to be thought on the same level of quality, we had enough of going back and forth.

This part of the process helped us to understand what content was really important, so we decided to stop working on different part separately, and started to implement the whole game in one scenery that we were confident with.

But this was when the "iterative design process" came to us again, just like Bethesda iterative design process for their level design team we would make the whole world in one go, to have a rough idea of what the game feels like and to test out the mechanics directly in it. No real grey boxing, just implementing, even if it was not good, we would at least have all the content roughly placed in the game. We would then had an idea of what needed to be done, what to do next.

 

Figure : Implementation of content in the game.

 

From that point, we just implemented area by area, the game was finished at least once, then we came back to the first area and redid, rethought, replaced, modified, added content, then switched to the second area, and so on. One important thing was to make sure that everything was working when you left it, no programming issues, no holes that allows the player to get out of bounce

With this kind of process we had a game at any moment, it was playable for some school deadlines, and at any time we could take it and give it to anyone to get feedbacks. It’s different than when we were working on the individual scene where we had no real game, just graphics or mechanics. It was really hard for people to get into it, which means harder for us to receive feedbacks.
Being in this situation doesn’t mean that your game is on the way to be over, or in his final situation. We did change after few weeks from third person character controller to first person controller, because of deadlines and we were looking back to the initial pitch in which the sense of immersion was of high importance.

 

Figure : First person intégration !

 

We also changed whole parts of the game, starting with the tutorial area, which was sort of non-existent at the beginning. We did leave room for it but did not take the time to think about it. Later on, seeing that we had laid out the whole game and that it was working roughly, we came back to the tutorial and started to think about a better design, regardless of the rest of the game.

            

Figure : Left : top view of the tutorial area with the first iteration and just implementation of basic content. Right : top view of the second iteration. 

 

 

Figure : Joel Burgess GDC’s talk on “How We Used Iterative Level Design to Ship Skyrim and Fallout 3”

 

This gave us the possibility to be flexible on the amount of work we chose to put in the game and to manage the time spent easily on the other school classes. At any moment we had a working game that could be showed. Every team member could choose to go in and implement an area or modify it without being in any “waiting” state with the other members of the team.

 

So if i had to summarize what I’ve learnt with the team :

 

  1. Lesson: first concept and planning are very important, it lays out the bases to see if everyone agrees and has the same idea of the project.

  2. Lesson: iterating alone should not take more time than just the bases, it can be cut, but be confident, do your work how you like to do it, the team is mature enough to understand what you are doing and how you do it, and if you put enough love and passion in it, it will stand by itself.

  3. Lesson: big thing that I learnt, staying on the prototype and ask everyone for feedback. Because iterating on the prototype is one of the most important starting process, when you are at the end of your game and you realise that you did something wrong, it might be too late to change it, and your game will remain with this "bad" or “wrong” thing in it. As soon as you realise something doesn’t work, change it or get rid of it.

  4. Lesson: ask to as many people as you can for feedback, don’t be afraid to show your work.

  5. Lesson: don’t “prototype -> implement direct feedbacks -> prototype. ->...”, take your time to put feedbacks on the side, and get on it after a circle of iteration. Wait for many people to tell you the same thing before thinking about changing it.

  6. Lesson: this lesson is not really part of the process but it helps iterating to stay on the good track, to improve your gameplay, always look at what can make your game cooler, or more appealing, not something that could be boring. Boring stuff will not bring feedbacks, don't fly away from your initial pitch for a "better" gameplay.

  7. Lesson: be patient, good things come to those who can wait and don’t expect too much, go for simple content and iterate on it to get it more complicated.

 

There are certainly more that I could write about this subject, and more lessons that I’ve learnt from this experience, but I tried to summarize as much as I could.


I will finish with giving thanks to Raphaël Rainard and Alexis Coteur, members of the team for "Research" and also thank you for reading,

 

Antoine Fauville. 28/04/2017.

Video reference Gdc Joel Burgess : https://www.youtube.com/watch?v=PhW8CY8XkFg

 

Will be updated :

The Game will be aviable soon, here is a temporary secret link if you want to already test it out : ( More feedbacks at [email protected] if possible !) 

https://antoinefauville.itch.io/research?secret=KvvnJEHuvxhHFnohecDi2iuEhA

 

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like