Newsdio: Iain McManus Blog – Making 12 games in a year: this is what I learned

0
8


The following blog post, unless otherwise indicated, was written by a member of the Newsdio community.
The thoughts and opinions expressed are those of the writer and not Newsdio or his parent company.


In 2019 I made a collection of 12 games that I launched all at once in early 2020. I learned a lot during the process of creating the games and I would like to share some of what I learned along the way with people.

the

During the last years I have participated in the Global Game Jam that runs every year. It is an event that I love to do and it has always been a fantastic atmosphere on the sites. One thing I often struggled with during the GGJ is the reach. My game development work has been mainly in large projects (several years, large teams, heavy systems, etc.). I also love to design, build and play heavy systems and heavy narrative games. That doesn't work as well in a game jam with a very limited amount of time, or to deliver reliably in solo development.

A graph that shows the total development time of each game. Each game had a maximum of 24 hours. Most had between 22 and 23 hours.

After the last GGJ, I was discussing this with one of the team members and they suggested that I pose the challenge of doing a lot of small games, which is how this all started. The overall goal was to improve the reach, learn a lot of new things and have fun along the way. I also decided on some rules for myself, namely:

  • I work in one game at a time.
  • For each game I get 20 hours and after those 20 hours, the game must be loaded and ready to launch.
  • The 20 hours include everything (ideation, design, assets, programming, testing, project page, lighting compilations, compilation loading, etc.).
  • Once all the games are finished, I get 4 final hours per game to polish.
  • Once all games are ready, they are released simultaneously.
  • All games are solo projects, although I can use third-party assets or reuse the work of previous projects.

I was happy that the rules provided the right combination between keeping things focused and allowing enough freedom to produce something that felt substantial. 20 hours felt achievable as long as I focused heavily on a single mechanic or system as the centerpiece of the game and whenever I planned well.

What tools did I use for the projects?

Due to the short time constraints, I was left with tools that I have used extensively and I was sure it would save time, or at least not make things difficult.

  • As for the game engine, I used Unity 2019. I updated the latest versions between games, but blocked the version once 2019.2.12 came out to reduce possible problems.
  • Within Unity I used a lot of additional assets / add-ons / packages (Fungus, ProBuilder and TextMeshPro).
  • For all the audio I used WWise and if I was composing music, I used GarageBand.
  • About half of the games were developed on Mac, the others on Windows. I change a lot between them to try the games.

In terms of what I learned from the series of projects, I want to focus primarily on areas that are transferable to other projects rather than specific technical systems or solutions.

Scope of planning and production together with the project.

As someone who has worked on games for a while and who also taught game development, I have used many tools to plan a project and manage production. I am also someone who has really had trouble finding planning and production tools that feel they work well when I am doing a game or a small project. I have very little patience for a tool or process that is cumbersome. As soon as it seems that it is holding me back and / or does not add value, I will throw it away and look for an alternative or create my own solution.

However, that has not often been a great approach. I can waste a lot of time making my own solution and it easily cannot be better than what I already had. And if I don't use any solution, or I don't use an effective one, then that gets in the way of making the project have the level of quality I would like. With the objectives here of delivering 12 projects, launching them all at once and finishing them in a year, I had to use something.

For the first and second project … I didn't do it. I used Toggl to track my total time, but that was it. Nothing in terms of managing tasks or times or even a written plan of what the game would be. To all the producers who read this … I'm sorry and I learned my lesson! I was lucky and the first game worked. I delivered a game I was happy with and the development was quite fluid. I … very foolishly, I didn't recognize the level of luck that was involved there and I did the same in the second game … it didn't work out.

The first game in the series was called Cat Maths. You are stopped and the teacher's cat is throwing you math problems.The second game is called Closing Down. You have entered a small corner shop on your last trading day. Your friend wants to steal things. You can help them or work against them.

I burned approximately 25% of the time in the second game designing, implementing and debugging a moderately complex dialogue system. It was based on data, had status, had items that could be displayed according to status, could avoid repeating options and worked perfectly. He did everything he had coded to do. I have all the data settings inside, everything was perfect. Then I executed it … and the flow of the conversation was not happening as expected. I spent hours checking the logic … checking each conversation … there were no errors.

It was only after several hours that I realized that what I had built did not have most of the features I needed. I didn't have time to do it correctly (that is, I actually designed it this time), so I ended up having the tricks I could do to make it work more or less and the game suffered as a result. This was a game that depended on making the conversations feel good and my beautiful, data-free and error-free system could not fulfill it. If I had even spent 30 minutes planning the features and technology, everything could have been avoided.

A photo of the planning notes for subsequent games. I used paper to plan level designs, plan mechanics and systems and keep track of the remaining tasks.

However, I learned from this and the rule I established in the future was that I had to plan things on paper. Then, the task lists with estimated times were on an A4 page (if you needed more pages or another column, the scope was too large). Periodically, or if a task took much less (or much more) time than expected, it would redo the list of tasks and the estimated times. I would also make level designs and sketches of key elements within the game to act as a visual reference. That helped substantially with all future games and felt on a scale that was feasible within a game jam or a very small project. I'm still not sure what I will use for projects a little bigger than that, I would probably take the blow up and use a digital system.

Key lessons

  • Plan, Plan, Plan.
  • When a task takes much more or less than estimated: Replan.
  • At regular intervals: Replan.
  • Not really, really plan.

Recognizing when an idea does not work

When I develop the idea of ​​a project, I always pretend to be able to imagine the game in my head and be able to play through it. I try to visualize what the player would be seeing, how they are interacting with the world and how that looks at each moment.

However, that doesn't always happen, sometimes I just can't imagine an interesting version. Other times, the image keeps changing and never settles. In the past, what I often have is to push him and make the game anyway and wait as he makes it clearer. If you have worked on a creative project, you are probably shaking your head or saying desperately "noooooooo" … and rightly so. For me, at least that approach has never worked, games always end up being something that loses the brand I was looking for and end up being frustrating to work.

The sixth game in the series was called Resist! In the game you are encouraging the other people in the village to face oppression by destroying propaganda and other tools used to oppress the village.

I was lucky with this set of games that I only found in the problem with a game. That game, Resist!, Was frustrating at every step of development. I allowed myself to look at the mechanics I wanted, that I was the player who destroyed the propaganda and that caused the community to rise against oppression. The mechanics were interesting, but I could never find a scenario or an expression of the mechanics I was happy with.

I considered everything, from a futuristic version with a floating city floating over an oppressed underground city to a fantasy setting. I thought about having AI characters that would chase anyone who attacked the propaganda. I considered many options and none of them created a compelling image in my head. Unfortunately, instead of recognizing that it was a problem, I went ahead and the result was a game that did not hit the mark. It did not convey a point with any impact and did not have an interesting game or environment.

What I should have done, and what became a rule for me in later games, was to obtain external information and make changes. With all the subsequent games, I set out to talk about design and design challenges from the beginning with my friends. Obtaining that external information, even articulating the idea to another person, was immensely useful.

Key lessons

  • Obtain external information early and frequently.
  • Don't try to force an idea if you don't find it interesting or compelling.

Driving simple systems with data

As I mentioned at the beginning, I love to design, build and play games with systems in them. Inevitably, that meant I was going to tend to build games in the series that would be system based. In the past, I often tended to design those systems too much. Make ones that are too generic (without the use cases to back them up) or that have such complex data that they cannot be used without an editor and specialized debugging tools.

I knew that if I fell into that trap in these projects, I would burn a lot of time and there would probably be nothing to show. To try to avoid that trap, I set some restrictions to help:

  • No custom editors
    • The idea here was that if the data could not be configured within the Unity inspector, then it was too complex a configuration for the scale of the project.
  • Shallow data hierarchy (ideally flat)
    • This relates to custom editors and the goal here was not to have many nested data structures. I wanted to keep the complexity of the data structures as low as possible to minimize the possibility of errors.
  • The data must be quick to configure
    • The data for a dialog line should take 30 to 60 seconds to configure. Data for a character's statistics, also 30-60. The complete set of data for the game should take up to 15 to 30 minutes to configure.
    • Something more than these times and was probably beyond the scope of the project scale. Keeping the total time low meant that it was quick to get things going and keep the individual times low for faster iterations.

A screenshot of a pair of programmable objects used in the 12th game that shows the settings for the second wave and the settings for the second level of weapons.

Ultimately, what I used was sets of programmable objects. In rare cases, a programmable object would refer to one or two more, but never more than that. The depth of the data structures was also maintained in 1-2 layers in all cases. That approach worked well and meant that it was quick to have something in operation and also fast to iterate and improve it.

The approach also, for the most part, would also work on larger-scale projects. In a larger project, it would retain the limitations of making it quick to configure and iterate on the data. It would also have restrictions, although larger, on the depth of the data structures. The main change would be not only to allow customized tools to edit the data, but also to ensure that they are given dedicated time to develop strong and fast tools that help the team work better.

Key lessons

  • Establish rules for the complexity of your data based on the scale and scope of the project.
  • If a front-end is needed to manage the data, make sure that its continuous development and maintenance have adequate resources.

Properly evaluate new technologies.

I have been using Unity for several years and something I have sometimes been guilty of is not properly evaluating new tools. And while it is absolutely important to make informed decisions about the new tools, I am wrong to continue with what I know. That manifested itself absolutely in most of the games I did on the set and in some different areas.

The third game in the series (What happened to Survey Team 4?) It had a day / night cycle as a crucial element. I spent a substantial part of the time developing a data-based system that could adjust multiple lights (angle, intensity and color), as well as ambient lighting and fog to create a day / night cycle that worked well. Only one thing was missing … a changing skybox. For which he did not have an immediate solution, it was not something he had done before.

So I researched, not because it was the intelligent movement, but because I had to do it, and I found a great solution. That great solution … was an asset that changed the skyboxes, the weather and managed the day / night cycle much better than my solution (easier to configure, had excellent default values ​​and more adjustment options). I ended up eliminating most of the system I did for the day / night cycle because it was now redundant. If I had recognized that the skybox was unknown to me and had investigated it first, it would have saved me 1-2 hours, which in a 24-hour project is substantial.

The third game was called

Above all, but not quite, I learned my lesson about proper research at that time. Which meant he had new mistakes to make. Many of the games, particularly the latest games, needed to mix between different cameras or have a specific sequence of events. In particular, in Fragments, the final sequence caused the player to interact with a giant artifact. The artifact would move in response to this, its material and lighting would change and a sequence would develop where it was thrown up and the player's camera would follow.

I set it manually … mainly in code. I coded lerps for lighting and movement, started the audio at different times, manually coded the logic to override the player controller to look at the artifact. It was honestly a disaster. It took a long time (more than an hour) to set it up and adjust it to the point where it worked in a tolerable way, not well, just tolerable. Worst part? I knew there were Cinemachine and Timeline and what they could do. He had never used them before, but he had seen them used. Because I never tried them, although I didn't even consider using them.

The seventh game was called Fragments. In the game you explore a seemingly abandoned installation in a world where reality itself has fractured.

When I polished fragments again, I had used Cinemachine and Timeline. That was due to having projects (Encore and A Wizard & # 39; s Life) that would have been a nightmare enough to do manually that forced me to consider other options. During polishing I changed the final sequence to Cinemachine and Timeline. In less time (20-30 minutes) I put together a final sequence that was better than the manual and aligned it with my vision. The only code snippet he used was to blow up the roof. For me, the great conclusion of this was to always make sure to evaluate the technologies I am using for the solutions and make sure they are correct. When new tools emerge, I also want to invest the time in making a quick demo scene with them to know what they can do.

Key lessons

  • Research first. In particular, investigate the areas you know least first.
  • Plan what technology you will use and make sure you have a reason to use or not use something.
  • Invest time in trying new technologies.

Be kind to myself

Working on any project will have good and bad times. Development does not occur in a vacuum and will be affected by what is happening in the lives of the people who work in it, as well as in the project itself. During the development of these games I also worked full time, so these games had to fit into a full time job and everything else.

There was also a tendency to pressure me a lot. Assuming the creation of twelve games, with tight limitations and wanting to do it in a short period was a lot. I wanted the games to connect with people and for people to enjoy playing with them. He also wanted to do different things in the games than he had done before. I wanted to have some games with a story that would hit hard and others where I would ask the player to literally do nothing. All that created a lot of pressure to work on the games.

A graph that shows development hours per month. From February to April there was a constant accumulation as the momentum accelerated due to the improvement of work patterns. External factors caused its collapse from May to July. That improved in August until October and then really picked up at the end.

However, that pressure ran into the reality that I am human and that I had a full-time job that should have priority. I was lucky that I really enjoy my work, but as I say to my students: it is easier to work on the things you love. There were days, many days, where I would run out to the point of falling asleep on the bus on the way home (sorry to any fellow traveler if I snored). Trying to work on the projects at that time was difficult. Creative work is not something you can polish by brute force. Finding good solutions, the types of solutions that are efficient and provide a great player experience, does not really happen when you are tired. It took me a while to recognize and fully appreciate it and find a good approach to manage it.

What I decided in the end was to set time limits on the work blocks I would do. I would not sit down and pretend to do 4 hours. I would make blocks of 1-2 hours and then take a short break. If I felt that I could do another series of jobs after the break, I would. I would also start the work blocks by doing smaller tasks. Those who did not demand creative solutions and who were solving family problems. I would use how that was as an indicator to see if I was in the head space to tackle larger tasks. If it were, I would move to the larger areas. If not, I would take a break until later in the day or the next day. The key there was to try and then give me permission to rest.

Key lessons

  • Find a work pattern that works, not against, how it works. For me, that was 1-2 hour blocks and the use of some tasks as an entry point. However, it will be different for each person.
  • Be kind to yourself and give yourself permission to rest when you need it.

I learned a lot during the creation of these games. Along with the previous lessons, there were many new tools and systems in which I immersed myself. At the end of the series, I reached a point where I could feel quite sure of knowing what I could offer in the term and with what quality. I made many mistakes along the way, but the most important thing is that I learned how to recognize them next time and avoid them (in order to make new and more interesting mistakes!).

I don't think I will set the same goal of making 12 games in a year, but I'm very glad I did. If you want to see the games, the complete collection of them is available here.

LEAVE A REPLY

Please enter your comment!
Please enter your name here