Few weeks ago, I again participated in Ludum Dare and yet again in a team. There were actually three of us and we created the game in 72 hours for 'Compo' category. Some time passed and it is finally time to write a post-mortem.
Before going further, I'd like to point everyone out to the game and a walk-through video for it. The game is still available at:
https://ldjam.com/events/ludum-dare/38/run-u-fool
And you can view the video here:
[media]
Let me start with short overview of how it went, for me this was actually already 4th Ludum Dare if I'm not mistaken, and 2nd Ludum Dare in a team. The routine is fairly similar each time, we spend afternoon of the Friday discussing what could be made for each possible theme (as in Europe the time theme is shown is during our night hours), then going for sleep as we start working on the game early in the morning.
Originally we have planned a game with small planet or planets, but as we saw multiple people going for the same topic on Twitter, we decided to go different way. The concept originally was based on world getting smaller, while the player's goal was to run away to reach the next level, ultimately reaching another world and saving himself.
What went right?
Separating tasks between each other, while giving others insight every now and then. It all ended up so well, that everyone of us knew what we're doing and what we're going to do. The idea behind the game was a lot more simple compared to our previous Ludum Dare, where the game we mapped on theme was quite complex.
Also having an in-game tutorial this time was definitely a plus. It gave a player perfect idea of how to progress through game, we haven't received any feedback in sense that: players had no idea what to do. Which is definitely a success.
Technical execution of the game. I'm quite proud to what we have created technically within those 72 hours, as all art assets - models, textures, shaders & effects were done in that time frame. I even decided to put few selected effects as appendix into this "post mortem" to explain how we did it to other fellow participants.
What went wrong?
As each competition, time planning. No matter how hard you try - it will always go wrong. While all of us were mostly free on Saturday and Sunday, I was the only one finishing the game on Monday (with help of one another guy, who helped me with some final testing). The rest of the team had to be at work, and I took few hours off, to wrap everything up.
Main menu. That part of the game is definitely the one that is the least complete, with just few text-buttons to start levels. Nothing really interesting goes on there, and sadly we had no time to think off and create some art for it. Yet, it serves its purpose and has all the functionality we needed.
Build for website (e.g. WebGL). I already knew that browser builds are slow, after all I've worked with browser rendering through WebGL in past as a job. That was about 3 or maybe 4 years back. That was on a custom-built engine (mainly for rendering) which was faster than Unity in comparison ... since then browsers didn't really move a lot.
They are still way too slow to compete with desktop based applications (even the ones running on .NET beat them in order of magnitudes of speed). The solution? Reduced effects, reduced physics, shatters have about 1/10th of objects and it is still several times slower compared to desktop build on the same machine (and I'm talking about testing rigs with Ryzen 1700 + Radeon Rx 480 or Core i7 + GeForce 1070 ... on neither of those it was smooth in WebGL build).
Summary
Those were few of my basic points. All in all, I really enjoyed Ludum Dare and hopefully I'll participate also in the next one. It may be as a team, or solo. Which is still unknown, as the next one happens during the summer and I fear that some of us might be out for holiday at the time.
For those of you, who participated in Ludum Dare or are generally interested in what few effects we put out - with little details and/or description, please read the following sections. For the rest, I hope you enjoyed the game, and feel free to share any thoughts you have about the game (or anything you have in mind).
Appendix - Force Field Effect
Once we came up with and idea of the game, it was obvious we need some kind of blocking feature in the way. Such item was a force field. The first model I created was a gate to hold force field, as I was against just putting up a plane with some effect. The basic model looks like this:
[sharedmedia=gallery:images:8602]
Which followed by adding materials, by adding color, metallic and roughness I achieved the final effect for gate that holds the force field:
[sharedmedia=gallery:images:8603]
Now the final effect, done by simply rolling multiple textures one over another - changing intensity and using some random rolled texture as offset. The final animation is in there, although in my opinion it can't be noticed unless somebody really looks at the force field. The last part was lighting itself, which is done with multiple point lights to simulate the effect of area lighting from the actual force field. The final look:
[sharedmedia=gallery:images:8604]
And also a video of effect in action:
[media]
Appendix - Chain Physics
As the development of the game progressed on, we realized, that the player can go through the levels without too much effort. So the idea was to block his progress through the game somehow. I spent some time adding some rigid body objects, but those were not enough to block the player.
You can literally go around, or just knock them. Which brought me to the idea, what about some chains that would slow you down. The chains had to react based on the physics of course, and as objects have mass - when you push them it will slow down your speed. But visually they have to behave as 'rope'.
At this point there was no time to write some advanced 'rope physics' from scratch with a lot of parameters. So I've settled with simple idea, use few rings in chain as a rigid body and add hinge joints in between the nodes. The result was this:
[sharedmedia=gallery:images:8605]
And here it is in action, I was surprised how good it looks in movement - so I didn't really touch it anymore. It did its purpose.
[media]
Appendix - Shatter
Once our idea for the game was settled, I noted that we do need to have some special effect for floor falling apart. The idea behind everything was to use a 'Voronoi shatter' technique to break down the floor. So I've prepared whole floor model and the one with dozens of objects in which floor shatters.
[sharedmedia=gallery:images:8606]
First idea was to just let it 'explode' downwards, but it didn't look really good. What we did in the end is, that once floor tile was determined to be destroyed, the whole object got disabled, while shatter one was enabled. Each single voronoi cell had rigid body assigned, but without gravity applied and kinematic flag set to true. Along with that we added a random timeout at which the cell gravity was re-enabled and stopped being kinematic only.
By cleverly playing with parameters we ended up with acceptable animation looking like this:
[media]
