Ahh! I'm loving the art style a lot! I second J on the icon haha - I'm super excited to see how this ends up!

Day 03:

First day of the jam where both of us are working our day-jobs, so we've not made huge leaps in progress today. 

The scaling of the moving objects (player and trash) was still a problem today... and that's without scaling the box colliders and the rigidbodies along with it.
With some fiddling and googling and brainstorming with the Onion-friend, things are looking up again, at least on scaling the object. 
If the scaling turns out to be too much of a stumbling point that's costing is a lot of time, we'll probably have to push it back and see about getting back to it when other things that are more important to gameplay are complete.

Art-wise today was focused on the second background-state. 
Originally I intended to go for three states: The polluted beginning, a midway point and the "win screen" final state. But I'm thinking to both make the changes less jarring from one state to the next, I'll include a second middle of the game state.

These are the two states I have so far:

If we've a lot of time left, we'll want to add some animation bits to them as well and I'll be cursing myself for not drawing it all more split up.
We'll also need to think about how the changes will appear. The current plan is to fade in the new state and out the old as seen above,... if we can figure that out in Unity ;)

Wah! I can’t wait to try this out~ The art and concept fit together so nicely...I’m in love with the little paper boat. Good luck with the movement scaling weirdness—you got this! (I feel like you’d enjoy playing “Flower” by ThatGameCompany.)

Day 05:

After three days off due to various reasons, we're back :)

Here's what we're currently struggling with: 
We have NO IDEA how to gradually change the colours and alpha of GameObjects in Unity, i.e. making the change over a few seconds when triggered, rather than changing all at once...
Pointers/Help would be GREATLY appreciated!

We keep looking at code people got in response to such questions, but it feels like we're still too early in our understanding to understand how to apply it.
It seems like it'd be no problem if we were dealing with a UI Image thanks to CrossFadeAlpha, but with GameObjects, it keeps us scratching our heads in confusion. 
We've been at it all day with no luck... Frustrating!

But let's get to what we did accomplish!

1. Trash that spawns now also scales, becoming bigger as it floats "to the front". (Onion)
2. Trash can now be collected. (Onion)
3. Collected Trash increases the Score. (Onion)
4. Finished all four Island states. (Bean)
5. Started on a Start Menu using this tutorial. (Bean)

To-Dos:

• Figure out how to change colour properties of GameObjects gradually, rather than suddenly, when a certain score is reached. (Help! We're so stuck here!)
• Create "End/Winning" State
• Finalise Start Menu incl. Help- and Credits Panels or Scenes

I'm still in the early stages of learning Unity myself, but have you explore Lerp for changing colors?

Good job on getting through almost your entire game!! Better your game smaller than expected than too big, right? It looks so cute to play and the artwork is absolutely perfect. Good luck fine tuning! :)

Day 08:

Slow and short day today - the weather is just too nice to spend much time at the computer.

Gave our boat a little wiggle with our new animation powers and adjusted the transition animations to make the change take effect from front to back:

Also worked on further setting up the itch.io page with screenshots, a cover image and so far a very very very short info text about the premise of the game.

Adjusted how much trash spawns and how quick it moves, making it spawn less frequently and also go a little bit faster after each transition. Might not be the final state yet, but getting there.

Still have to do an end screen. Would like to have non-trash floating on the water for that, but not sure what kind of stuff that would be...? We'll see if we can think of something. 

Only have about two evenings left to really work on things. 

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.