Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Lessons In Making A Serious Game During A Crisis

    [06.30.20]
    - Kim Kupiainen

  • While I had my head caught up in the Sound design, I thought that the project was going well. After that I noticed that our Art team had started slowing down, and begun being somewhat inconsistent with the implementation of the art assets.

    I asked the art lead about task prioritizing. He said that to his knowledge they've done all the tasks that are needed currently. Me and him together went through what they had done, and realized that while they had done more than they were asked, they didn't necessarily do the tasks in the most efficient order. And we were going to move from production to polish in a week.

    There was a sauna that had been made for the game before we had all of our trees for the game scene. I think that it's most important to have things that you see most of the time, be of the greatest fidelity. Because the player sees trees everywhere, but the sauna is seen in a single place on a 2 square kilometer island.

    As a lead/Producer, I like to give more faith to the leads than is comfortable for me. I do this because I believe it creates a foundation for self-guidance and as we're in school, We're not in danger of losing our jobs. I believe in facilitation of communication, and making sure that we have everything we need to push the project through. It also teaches me to let go, instead of slowly falling in to the void of micromanagement.

    As we moved forward, the art assets started pouring in, but GIT was a new concept to the artists, most of the assets had to be reimplemented multiple times, as assets would go missing from the project folders and people in the art branch didn't exactly know how to use these kinds of tools.

    This is no surprise, as version control is something that is not gone through actively in art-studies of game development in my school. The problem was tackled by us though. Our programming lead made our artists a simple documentation that went through how to push and pull, how branching works, how to build a feature branch, merging and so on. Artists started trusting their skills and started pushing more assets. At this point, a fire was brewing somewhere else.

    We moved from production to polish. No more assets would be added to the game. At least that was what I promised myself.

    Our programmers in the team started merging scenes together to make sure that every and each puzzle works the way they are supposed to. We ran into problems with git, problems with merging, communication and constant breaking of heard information due to bad Internet service providers.

    This put us backwards in development from the schedule, but not by a lot. We had one crunch weekend and I personally have this night, when I'm going through everything I've learned, before going to the stage to present our findings and lessons from the project.

    We worked 7,5 hours a day, 3 days a week. Putting us in to 4282 hours of development time in total on duration of this whole project. With crunch we gained more time to do useful things, but we did not make a perfect game.

    Everyone was present for the whole day to the best of their ability. Even though we had to go to school from home. The lessons while going to school from home took a toll in the quality. And so did our project too, obviously. Because many problems can be debugged way faster when working in the same environment.

    In the end, we have all the puzzles that we originally designed, but the implementation suffered from the beginning and the way people had been working separately.

    20 items in the backlog, 7 in the last sprint. All with the tag: CUT or bug

    Here begins the TLDR part of my first blog post on gamasutra.

    Lessons learned:

    Production

    • Pre-production of 4 weeks is too short to make consistent systems to build our game and make proper plans for development
    • It is important to focus in systems instead of small self-contained items
    • What you see and hear the most in-game, should be prioritized the most
      • Context here is that we shouldn't build extra assets before having the regular important assets like trees and stones.
    • At first more freedom and then slowly tighten the grip towards the end product.
      • As in art, broad strokes first
    • Serious games can be fun to make
      • But seriously they are harder than anything I've developed so far.
    • Applying for grants is hard, but getting the money is even harder.

    Our team of students have been a really hard-working one. There were no people in the development team who'd disappear without a reason, even though this is a school project of 12 students. I love these people, and personally I have nothing bad to say about a single one of them. I'm proud of them, they've learned a lot and have been working both hard and smart to the best of their knowledge. I've done my best at that too. And in the end, we've all learned a lot.

    I'm truly thankful for this experience, and hope that you enjoyed reading my collected thoughts through.If you have any questions about this project, feel free to comment. I might make a continuation post in the future.

    Thanks to our team members at Lakes-12 and especially our playtesters and our Cognitive psychotherapist Kirsti Pyhäluoto-Keränen

Comments

comments powered by Disqus