Plastic
Sea – Post Mortem
Getting Started
When it was clear we wanted to start making a game, we looked at the itch.io calendar and conveniently for starting on our first game ever, MyFirstGameJam was just around the corner.
We talked about the theme and came up with a handful of ideas to base a game around. We’d been tossing about the idea of a game that addresses the pollution of the oceans before, so this idea stuck.
The basic concept was defined: Steer a boat, collect trash, change the environment.
We also knew that we were going to work in 2D. It’s appealing to both of us, so we’d both chosen our courses to work with Unity in 2D a while back.
The art style was also defined very quickly. Our icon/page-art has the same paper cut-out aesthetic that we think is quite charming with the art style in it, so we decided to keep it, even if we didn’t enforce it on every little detail (e.g. the background island is a cut-out as a whole, rather than individual buildings being individual cut-outs layered over one another).
We drew out a table with different stages on a big piece of paper, defined columns: - for things to do that were mandatory for the game experience,
- those that were optional,
- what we’re currently working on
- and what we’d completed.
We filled the columns with colour-coded sticky notes depending on whether the task required art or coding and put them in order based on priority.
We also transferred this information and elaborated on it in a trello-board, which was neat since Bean uses JIRA at work and is familiar with that kind of setup.
Working through it
We got started, created first assets, made sure things that were supposed to move did and others didn’t.
There were some revisions to our wave-assets on the first few days.
They started out much more detailed, inspired by waves in paintings, but we dumbed them down a lot because they took away too much from the clarity on the screen. They made it all too busy with too much white, too hard on the eyes to make out the trash in it.
We tried dumbing them down little by little and eventually decided to keep it simple and try to keep the white cut-out aesthetic only on the last row of waves.
We also added one more state to the background than originally planned, to make the transitions more reasonable.
With programming we hit two snags:
1. Scaling the objects as they move from the back to the front.
It had been no problem to get the boat to move, but we had so learn a lot about the logic of the code and how to limit and adjust and were to put code.
At first we found the boat would scale down to 0 and then flip on it’s head. We adjusted the scaling better to the area the boat could move in.
Things seemed to work, until we realised that the scaling was tied to the how long it took to get from one point on the y-axis to another – so moving diagonally made the size change more and the boat could still be flipped.
We worked it out relatively quickly, though, with the help of our Onion Friend, who hadn’t worked with Unity or C# before but has general experience with programming and understands the logic better than we do.
2. Gradually changing the background island and waves with the player score.
Again, the start seemed simple enough, when we made the score rise with every trash object colliding with the player, but we had some trouble getting the script that changes the island to recognize when a certain “phase” had been reached.
Once we figured that out, we realised we didn’t understand the script that faded out one island and was supposed to fade in another enough to make it work.
We sunk a good two days into trying to work out a solution to fading out one object and fading in another, again with some help from the Onion Friend.
At the end of the two days we had a bunch of scripts, one for each island, that sort or did the job and no idea how to transfer the effect to the water without having to add another dozen almost identical scrips.
The turning point came with a comment on Twitter suggesting we use animations. We had already started dabbling in animations for a simple fade-effect between the different scenes, but it hadn’t occurred to us to use it for this at all.
Within an hour, we fixed the problem and got it done.
After that we mostly worked on cleaning up, adding an end screen, allowing the game to be paused and setting up the game page.
What was good?
We made a game! It’s short and not complex, but we hope it’s a nice, charming experience.
We’re super proud that we took this step and managed to complete it!
The scope was just right for us, allowing us to complete it and still have time to work on some optional things, though not all.
It was important to us to keep it simple, to keep it manageable, to factor in that we’re absolute beginners with game development, Unity, C#, programming in general, etc..
Setting up a board with the plan worked well for us to keep track of tasks, even when we added new ones during the development.
It was also great to have a community of like-minded people who encouraged and helped each other. Getting positive feedback was great to keep motivated and reading about other projects helped put things in perspective.
And it was fun to connect with others via social media – in our case on Twitter and Instagram. Though we were in the Discord Channel, we didn’t use that a lot. Looking at it here and there, it was kind of a surprise to see a whole different palette of projects than on Twitter, for example. Might also look into tumblr in the future.
What do we need to improve on?
There’s two major things that we’d likely profit from getting better at:
1. Comprehending solutions we find.
A lot of the time we’d look for solution through tutorial videos or skimming through responses to other people who had had the same or a similar problem in the past. Often we would simply try out the code given as a solution and if it worked that was that for us – until it didn’t work. And when it didn’t, we couldn’t really pinpoint why, because we didn’t know why it had worked or was supposed to work in the first place.
So while it was good that we practised gathering information and finding pointers for solutions, we hope that the more we learn about Unity and C# in general, the better we’ll understand the solutions and will be able to learn how things work for the next time we use it.
2. Getting hung up on challenges.
Above we mentioned or two big programming problems, the second of which cost us two days of us both looking for and trying out solutions and caused a lot of frustration.
We’d probably have been able to elaborate on some things if we had dropped the topic for a few hours or even a day or two to focus on other features.
This second programming snag also caused us to burn out. After two days of absolute frustration, the solution was so simple via animations that it was actually a bit demotivating.
We were done with all major features with still 3~4 evenings left to work on the game, but didn’t get nearly as much done during those as we could have. We were worn out and tired and wanted to just finalize things, but didn’t manage to do that as fast as we could have either, dragging out small tasks over the remaining days.
And then there’s a bunch of other things, too:
We didn’t really use our trello board after setting it up, instead relying on our paper board with the sticky notes, despite trello allowing for more detailed descriptions, checklists and so on.
We didn’t really go out of our way to find people who could help us with our problems and relied mostly on hoping to find a solution someone else had asked for in the past. So we could’ve been more direct and active in seeking answers.
We’re also fully aware that our gameplay is very very basic and absolutely nothing to write home about – the game works due to the theme, the beautiful music and the aesthetic, we think.
This is owed to us being so totally new to everything, but that shouldn’t be an excuse and one of our goals for future games should be to provide more engaging gameplay mechanics as well.
Also, we should’ve put the Help and Credit panels from the Start Menu in other places: Help, giving the objective and the controls, would’ve served better in a screen between the start screen and the game, while the Credits probably would’ve been better after game completion.
Where do we go from here?
MORE JAMS!
It was a good experience and we feel that while tutorials and udemy courses are good to get basics down, working on the game really forced us to use and transfer the knowledge and our acquired skills.
So before we start any smaller or bigger projects on the side, we’ll work on strengthening our skills by taking part in more jams and switching up who does what, too.