It's been long coming, I'm pretty slow at coming up with everything I want for a post. I wrote something, then deleted everything and started again numerous times. And I have two more coming now! I can't just keep delaying it so I'll just write a shorter version than I initially planned and get on with it.

A lot of the lessons learned from that project were already brought to the following one, which is good. This jam's theme was "Cycles". We decided to include the most cycles we could into a single game. We have a day/night cycle, seasons, dynamic weather and we ride a unicycle. I wanted the game to have a similar feel to the Alto series not to rip them off or anything, but just to see how such a game can be made. It's usually my goals with each game jams, find a somewhat novel idea based on the theme and try to implement already known game mechanics. It's not because I don't want to make anything original, but I truly want to understand how things are made.

What went right

Since a few years I work as a photographer for the MS Dockville Festival in Hamburg, Germany. I share here a few photos from that special music festival.
Photo by Pablo Heimplatz / Unsplash

The art style

We decided pretty quickly how we wanted the game to look, soft pastels colors and a simplistic atmospheric design. Our artist nailed it, the game had a polished and cohesive art style which was absent from our previous game (granted the last one was our very first game). We went through a bit of issues with the animation pipeline but that trend continues on even today. I'm not sure how to solve that one without just adding an extra artist to help our current one.

The music

So for the previous game, music was an afterthought. Well. I actually wanted to try composing something but I heavily underestimated how talented you had to be to compose music. This time, I asked one of my good friends to write us something. He ended up officially joining the team and has been making music and programming with us started from this project.

DJ at work
Photo by Marcela Laskoski / Unsplash

I wanted to try implementing dynamic music into the game. The music would ramp up slowly as you progress, adding new instruments and complexities as you keep going. It would also change depending on the time of day and change along with the seasons. I almost forgot the weather effects too. Everything would also need to loop perfectly at nearly any time. All of that in essentially a day. And he did it. We ended up with about 250 Mb of music and it was one of the highlights of the game along with the visuals.

Endless

Now that somewhat worked, we had an endless procedural game. So hurrah to that, our game didn't finish in 5 minutes.

What went wrong

Shot made while filming for yesHEis project
Photo by Nik Shuliahin / Unsplash

The animation pipeline

So we wanted to do a pretty complex animation system so that our character could do tricks and other fun stuff. That all requires a lot of animation and its a lot of work if you do it in 2d. I've been pushing our artist towards 3d for quite some time, not because I hate 2d or anything but because once the initial modelling and rigging curve is done, you can produce animations at a much larger scale way faster, you can also iterate better and improve the thing without having to essentially redo it. So a large portion of the first day was to make a 3d model, which our artist did but when it came to rigging it, the automatic rigging from Maya failed and he immediately gave up. He moved back to 2d sprites which meant scaling down the game. In the end we would have done 2d using the 3d model as the base then making sprites out of all the animations to save time. If you have to draw all the sprites then you can't just make as many animations as you'd want in a single weekend.

So back to 2d he goes. He looks online to pick a software to help him make a 2d skeleton so he can save time instead of drawing all the frames. Which I agree would have been great if all the fine prints were read for how much he would have to pay come the export time. All the progress up to that point is once again discarded. In the end, he ended up using the tools in Godot to animate. He almost gave up twice but after much convincing he ended up sticking to it and making a few animations.

The physics

The way physics were coded was simply terrible. There's no other way to put it. A lot of it was a mess and it was near impossible for anyone other than the person that coded it (who didn't know what was going on) to even fix anything other than rewriting the whole thing.

Photo by Arget / Unsplash

The seasons, time of day and weather effects

Pretty much all hard-coded using animations and animation timings. I didn't know any better and should have looked more into it. Made it so we loaded way too many assets at once and made the game somewhat slow on some systems. The key to everything would have been shaders but I had absolutely no clue how to manage that at the time. The one good thing about it was that coding it went smoothly and it could have been much worse.

The gameplay

We basically had no game. You could do literally nothing, just walk away and never lose. No challenge either. You actually could only fail if you pressed buttons, it was impossible otherwise. We simply ran out of time and some of the other issues (mostly the physics) required so much effort to fix that it took all our remaining time.

In conclusion

It's still a big learning experience, we had a good time and will apply a whole lot of what we've learned this time to the next jam. This game still has potential if we revisit it, add gameplay, polish the physics and add some challenge to it. We will see.

If you want to try it out, you can do so here: https://worrygames.itch.io/mountain-run

And once again, later gamers