Sponsored By

A Hipster's Guide to Producing: Norn Aftermath

This is a follow up post from my last production article I did around 9 months ago and a lot have happened since. I hope this will shed some light into what small student teams should not take for granted in their productions.

Johan Ronner, Blogger

June 13, 2017

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

Hello!

 

around 9 months have passed since I decided it was a good idea to write down my thoughts in the hopes that someone else out there would find them interesting and useful in their student projects around the globe and now the time has come again friends.

 

At the start of this semester all of us wanted to test out the consumer VR space and play around with it a bit to see what’s really interesting with VR and what haven’t really been done before. Went though with a couple of iterations of ideas but none that really struck gold with all of us to keep working. It eventually got to the point where we just had to decide on something to keep working on or else we’d have nothing to show at all before our deadline. Jump forward 5~ months later and we have Norn to show for..

 

 

Norn is a stylistic nordic VR game about two sisters starting an adventure. In the current iteration of it for school only a hub area was built in conjunction with a couple of other technologies for our pre-production workflow all made into a vertical slice.

 

However this post isn’t about our game at all but rather about the process of making it and what I’ve noticed during it topoint out for future students making their big projects out there. I’d like to break it down into 4 distinct topics. Most of these I knew of before the production started but it became ever so clearly how important they really were whilst in the thick of it and I’d like to share that with anyone reading to hopefully not make the same mistakes. Again I feel like most if not all of these may feel very obvious but like my last post 9 months ago said, it’s easy to think about it, it's another thing to actually act on them. Please don’t underestimate these in your dev team.

 

 

 

Motivation ( or rather the lack of )

 

 

Now please take a minute to look for other advice regarding this topic, especially if you're prone to having issues with it yourself. You’re in it for the long haul and a slow and steady race is better than any sprint you’ll have. There’s a ton of resources out there. books, talks, blogs and youtube videos to help you with this if needed. Running away from it won’t help anyone so please take this seriously, not only for yourself but for the team you're working with.

 

We had some issues with this in our team and I specifically remember one of our teacher telling me to write up a contract. Nothing fancy, just stating what is expected from you specifically regarding the project. Even if there’s no money involved. I remember thinking - “that’s so stupid, we’ve worked together before and know what’s expected of us to make this work.”

 

I was wrong. When you give it your everything and don’t see that passion returned it rubs off in the wrong way. A contract could provide this in a more effective and constructive way. I saw this everywhere before we started this project, blogs, talks, my teacher and I still didn’t listen, thinking that I was above it. None is, trust me.

 

You’re a team, but a team needs guidelines to follow. Everyone's interpretation of that is different and shouldn’t be brushed under the carpet, for everyone’s sake. That leads me into the next topic.

 

 

 

Assumptions

 

Try your hardest to never have them, pretty please! They screw things up, big time! Assumptions are only guesses, some with much more knowledge and experience taken into account than others but still in the end only guesses. This makes them very dangerous to have inside a development schedule. Now let’s be real here, you have to plan and depend on others work to eventually do your own in any production but what if that takes a lot longer than firstly anticipated or even can’t even be done with your current knowledge or team setup? What happens then? In a perfect world all of this would be planned and executed in a pre-production phase but things could change.

 

Assumptions are there to guess ten’s if not hundred of work hours ahead of schedule and somehow make it fit into the current plan you're making for it run smooth until the very last deadline. Sometime it works, sometimes it doesn’t. Now it could  be done resonable well if your on your own. It's your work, your problems right? But again the notion of a team makes it so much harder.

 

Different disciplines with lacking knowledge of each other's pipelines makes it very hard to foresee any problems that is not your own, eventually leading to even more work for either one or both parties to eventually get it right. So how could it be solved? Communication! and lot’s of it!

 

Personally I don’t think all of this should fall on a producer's lap but rather should be encouraged by each team member to take interest and action on their own to make it work. They each learn from the process and hopefully by the end just a couple of lines of dialog is needed for it to get implemented correcty without any issues.

 

Each member should take responsibility for this to work as smooth as they possibly can and should never fall on just one person!

 

 

 

My Precious

 

 

Just like sweet Mr. Gollum here you need to have “your precious” in the game you’re making to even have the drive to keep working on it. Now this could be literally anything. Trying to get that perfect green color for your foilage lighting and spend 10 hours before you’re happy about it? go ahead mate. Find the things you believe makes the game you’re working on interesting and unique. That passion drives it forward and should never be pushed aside unless milestones aren’t met. It inspires the whole team to go the extra mile and be proud over their work. Try to never lose that magic!

 

I’ve recently got lucky to listen to a talk by Micheal Fredrickson, Technical Artist at Pixar who talked about the feeling of awe. To inspire something bigger and in a way unworldly to the receiver. He referenced the contrast to that idea by the person “Dave”. Dave just cares about the functionality of everything and nothing more. - "Oh that tree crown needs a color? and just puts on a greenish color in 2 seconds and call it done continuing to the next thing on the to do list. It may work, players will probably recognize that green ball as a tree crown at first glance but will later be taken out of the immersion they had thinking it stood out compared to the rest of the experience that had love and detail put into it. Everything needs to fit together in harmony. Gameplay, aesthetics, sound design and animations and VFX.

 

So don’t be a Dave, care about what you’re contributing to the project and If you really don’t enjoy anything at all about the current status of it you need to tell your team. Better to go a direction where everyone is onboard and happy with the process rather than just to fill a quota on the team just passing time. It’s not fair for either you or them.

 

 

 

Glass Half Full

 

 

I personally like to see the world in a more positive light than most, a bit naive to some but I really feel it helps when getting through some tough periods during development. People deal with stress and critique in different ways and it really shows during the low points in a production. My recommendation is to take this and just turn it around completely and laugh at it instead. Are an animation flippin out not working as intended and has caused trouble for the past 5 hours? Instead of getting angry which affects the rest of the team even more just laugh at it and post a video of it on twitter making fun of it. Make it into a joke, see the irony and use that to it’s fullest to fuel your energy further rather than deteriorate it even further.

 

In a small student team you’re working very closely to each other and emotions are easily mimicked so do yourself and the others a favor and don’t try to focus to hard on the negatives if something's not going your way and try to solve it with a joke. Just having a positive outlook when working with other will rub off, use that for your advantage and value it highly. It’ll go a long way in the long run.   

 

These are just a few things I noticed had a huge effect on the development of our game Norn. I’d like this small article peice to get other students thinking more deeply about this mindset and hopefully improve not only themselves but their team's well being as well.

 

Believe in your games and show that all the time!

 

 

 

 

 

 

 

 

 

Read more about:

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

You May Also Like